Lecture 3 - Requirement Analysis Flashcards
What are some more requirement classificiations besides functional and non-functional?
Requirement Priority, Requirement Scope and Requirement Volatility
What is Requirement Priority?
the higher the priority the more essential the requirement is for meeting the overall goal of the SW. A fixed-point scale such as Must have, Should have, Could have, and Won’t have.
What is Requirement Scope?
The extent to which a requirement affects the SW and components. Eg. Non-functional requirements such as response times have global scope: their satisfaction can not be allocated to a single component.
What is Requirement Volatility?
Some requirements will change during the lifetime of the SW and even during development. It is useful to estimate the likelihood that a requirement will change so that developers can consider designs that are more tolerant of change.
What are some viewpoints of requirements?
- Interactor viewpoints: people or other systems that interact directly with the system (eh users of a messaging app
- Indirect viewpoints: stakeholders who do not use the system, but influence requirements (eg payroll system)
- Domain viewpoints: constraints of the domain that influence requirements (eg healthcase system)
What is Requirement Negotiation or Conflict Resolution?
- The both concern resolving problems with requirements where conflicts occur
– between two stakeholders requiring mutually incompatible features,
– between requirements and resources, or
– between functional and non-functional requirements
=== - In most cases, it is unwise for the software engineer to make a unilateral decision.
- So it becomes necessary to consult with the stakeholder(s) to reach a consensus on an appropriate trade-off.
- It is often important, for contractual reasons, that such decisions be traceable back to the customer.
What are some ways to detect conflict?
Order of Priority
MoSCoW Method
Formal Methods
What is Order of Priority?
- Determining importance to the customers: Determines the degree of importance of each requirement to the customer.
- Prioritizing due to time and resources constraints: There may not be enough time or resources to implement all requirements, so the most critical should be implemented first.
- Identifying conflicting requirements: Helps to identify conflicting requirements.
- Planning for future releases: Can help you plan successive releases of a product by identifying which requirements should be done first, and which should be left to successive release
What is the MoSCoW method?
- MoSCoW stands for Must have, Should have, Could have, Won’t have (two “o” are inserted at appropriate places to give the word MoSCoW).
- # We can ask the client to group their requirements of the system into two lists: the DO list and the NOT DO list.Advantage:
- The MoSCoW rules have an advantage over the simple ranking method
– e.g., if there are many (say 1000) requirements then ranking using numbers from 1 to 1000 would be difficult, but grouping them into two lists using the MoSCow rules would be a lot easier.
What are Formal methods?
- Construct a mathematical model of the requirements
- Use logical analysis to verify properties and identify inconsistencies
- Most methods have tool support and some have automatic analysis
- Popular models include 1st order logic, set theory (eg. Z), temporal logic, state machines
What are the weaknesses of the ways to detect conflict?
- The requirements are NOT truly independent, yet all these strategies assume they are;
- The client might not know their priorities;
- Different stakeholders do not usually agree with the priorities of the requirements.
How do you resolve conflicts?
Negotiation
Why is negotiation important?
- Negotiation is introduced to facilitate requirements elicitation and analysis.
– Encourages communication
– Aids in understanding
– Reveal conflict, solution exploration, collaborative resolution
– Improves agreement level
– Develop stakeholders’ satisfaction
– Improves requirements quality
How is negotiation used in agile software?
- Negotiation for traditional software methods focuses on revealing conflicts and improving understanding of requirements.
- As agile methods focus on involvement of customer, whose role is to provide and prioritize new system requirements, negotiation for agile software development should therefore focus on resolving these system requirements, e.g.,
– Can they be implemented within the time frame?
– Can they be implemented within the budget?
– Can these requirements be prioritized?
=== - Agile methods have to rely on contract where customer pays for time spent on system development rather than the time on developing a specific set of requirements.
– Negotiate on what to be delivered, i.e., the product
– Software developer should be realistic on what they can deliver (i.e., do not over-promise just to get the contract signed)
What are the inputs and outputs of a feasability study?
- INPUT
– set of preliminary business requirements
– an outline description of the system
– how the system is intended to support business processes - OUTPUT
– a report recommending whether or not it is worth carrying on with the requirements engineering and system development process
What are some question you can ask for your feasability study?
- How would the organisation cope if this system were not implemented?
- What are the problems with current processes?
- How would the new system alleviate these problems?
- Does the system require technology that has not previously been used in the organisation?
- What must be supported by the system? What need not be supported by the system?
What are some issues with requirments and how does it link to requirements evolution?
- Issues
– requirements inevitably change. - Definitions
– a classification of requirements according to the types of change which may occur - Techniques
– SCM (Software Configuration Management), traceability tables, good record keeping, metrics
What are the reasons for requirement change?
- User gains better understanding of the requirements from the requirements elicitation, analysis and validation process
- New ways of working result from the introduction of the software system itself
- Changes to the environment of the organisation
- Changes to systems or processes within an organisation
Wha are the consequences of requirements change?
Consequences
* Increased costs – bad, leads to fights
* Delays, schedule slip – bad, leads to fights
* Increased cost + delays – really bad, bring in the lawyers, sell your house
* Can break “customer trust” – really bad, you lose the next 5 contracts as well as this one.
What are the best case and worst case scenarios for requirements change (in terms of the consequences)
Severity of the consequences depends when in the life cycle the requirements change
* Best case – review requirements specification
* Worst case – changes to requirements, design, implementation, tests and documentation
What is a traceability table?
- Uniquely number all requirements
- Identify specific aspects of the system or its environment classified by, for example,
– Features: important customer observable system or product features
– Source: of each requirement
– Dependency: how requirements are related to one another
– Subsystems: governed by a requirement
– Interface: relation to internal and external interfaces
REFER TO SLIDES FOR EXAMPLES
Why is it good to have a database for requirements?
- Manage requirements as a live repository
- Manage traceability tables
- Record rationale (reasons for a requirement)
- Record sources (where req. comes from)
- Record rejected requirements
- Identify volatile requirements (so they can be traced later)
- Overall to manage requirements
What are conceptual models?
- The development of models of a real-world problem is key to software requirements analysis.
- Their purpose is to aid in understanding the situation in which the problem occurs, as well as depicting a solution.
- Hence, conceptual models comprise models of entities from the problem domain, configured to reflect their real-world relationships and dependencies.
What is Architectural Design and Requirements Allocation
- At some point, the solution architecture must be presented.
- Architectural design is the point at which the requirements process overlaps with software or systems design and illustrates how impossible it is to cleanly decouple the two tasks …
- because the process of analyzing and elaborating the requirements demands that the architecture/design components that will be responsible for satisfying the requirements be identified.
What are Use Case Diagrams?
These describe functionality of a system from the users’ point of view
They show functions that produce a visible result for an actor
REFER TO SLIDES FOR EXAMPLE DIAGRAM
How is UML used in Use Case Diagrams?
UML notation to describe the functionality of a system as seen by the users in terms of:
- actors and their goals
- the system boundary: what is in scope and out of the scope of the system?
- the names of use cases for the system
What are actors in UML?
- external entities that interact with the system
- an actor can be a user role
- an actor can be another system
- actors have unique names and descriptions
- actors have goals that must be satisfied by the system
What is a Use Case?
- A powerful technique for identifying requirements.
- A user scenario is a sequence of events that a user performs in order to perform some function within the system.
- A table and text-based template is used to describe each use case
REFER TO SLIDES FOR EXAMPLE USE CASES
What are basic and alternate flow of event (in terms of use cases)?
- Use cases describe possible flows of events.
- basic flow of events describes what “normally” happens when the use case is performed.
- alternate flows of events covers behavior of an optional or exceptional character relative to normal behavior, and also variations of the normal behavior.
- Think of the alternate flows of events as “detours” from the basic flow of events.
Basic Flow of Events Example - includes alternate flows
REFER TO SLIDES FOR EXAMPLES
