Professional Documents
Culture Documents
Chap 3
Chap 3
Chap 3
Outline
The requirements workflow Metamodel for software requirements Requirements workflow details The importance of requirements Defining requirements
1
Defining Requirements.
Requirement: a specification of what should be implemented There are two types of requirements: Functional requirements: describe the desired behaviour of the system Non-functional requirements: specify particular properties of or constraints on the system In theory, the set of requirements should be only about what the system should do, but in practice it is not possible to avoid how aspects of the system
8
Defining Requirements...
The SRS (Systems Requirements Specification) is the document that contains the set of requirements expected to be satisfied by the system, both functional and non-functional There are many ways to write an SRS (company dependent ways) The SRS provides the input for the analysis and design phases of the development process The bottom line regarding the SRS is: does it help me to understand what the system should do or not?
9
..Defining Requirements..
Simple format recommended for well-formed requirements:
1 The ATM shall check the validity of the ATM card inserted. 2 The ATM shall validate the PIN number entered by the client. 3 The ATM shall dispense no more than $500 against any ATM card in any 24-hour period
Examples of non-functional requirements (constraints on or properties of the system): 1 The ATM shall be written in C++. 2 The ATM shall validate the PIN in three seconds or less.
10
Defining Requirements.
Organizing requirements: a more complex taxonomy can be used when there are many requirements, e.g. Functional requirements
Customers Products Orders Sales channels Payments Performance Capacity Availability Compliance with standards Security
Non-functional requirements:
11
.Defining Requirements
Requirements may have attributes, e.g.
Must have Should have Could have Want to have [the MoSCoW system] Status (proposed, approved, rejected, incorporated) Benefit (critical, important, useful) Effort (measured in person*day or function points) Risk (high, medium, low) Stability (high, medium, low) 12 TargetRelease (product version when implemented)
Finding Requirements..
Requirements come from the context of the system:
Direct users Other stakeholders (e.g., managers, maintainers, installers) Other systems that interact with the system Hardware devices attached to the system Legal and regulatory constraints Technical constraints Business goals
13
.Finding Requirements
The map is not the territory (that is, a model is not the real thing). When modeling, we apply three cognitive filters that simplify our effort [Chomsky, 1975]:
Deletion (information is filtered out) Distortion (information is modified) Generalization (information is abstracted into rules, principles, etc)
In requirements specification we need to identify the application of the above filters and find challenges for them to recover information In particular, universal quantifiers such as all, everyone, always, never, nobody, none should be inspected closely for accuracy 14
..Finding Requirements
Interviews:
Dont imagine a solution Dont mind read Ask context-free questions Listen Have patience!
Requirements workshop
Participants: facilitator, requirements engineer, stakeholders, domain experts Procedure: 1 Brainstorm (accept all ideas) 2 Identify key requirements 3 Iterate over, refine, and prioritize requirements End of chapter
15