1. Software Requirements and the Requirements Engineering Process
Chapters 5 and 6

2. References
Software Engineering. Ian Sommerville. 6th edition. Pearson.
Code Complete. Steve McConnell. (CC)
The art of requirements triage. Alan M. Davis. Computer. IEEE. March 2003.
Testing whether requirements are right. Robin F. Goldsmith, JD. Go Pro Management Inc. NYC Spin Meeting. December (RG)
Software Requirements. Karl E. Wieger. Windows Press.
Dr. Gotel’s research web page
Dr. Barrett slides, NYU

3. Requirements elicitation and analysis
Stakeholder: Person or group of persons who will be affected by the system (directly or indirectly)
All stakeholders should be involved in requirements elicitation and analysis
Stakeholders don’t know what they really want
Stakeholders express requirements in their own terms
Different stakeholders may have conflicting requirements
Organisational and political factors may influence the system requirements
The requirements change during the analysis process. New stakeholders may emerge and the business environment change

4. Different techniques for requirements elicitation and analysis
Different techniques for elicitation:
Brainstorming
Stories
Prototyping
Questionnaires
Interviewing
Viewpoint
Scenarios
Use cases

5. Requirements analysis
Read the paper ‘The Art of Requirements Triage’, Alan Davis, IEEE computer, March 2003
Prioritization, estimation of the resources to satisfy the requirements, subset of requirements that optimizes the probability of the system’s success
MoSCoW Criteria for requirements triage:
M – Must have – mandatory requirements that are fundamental to the system
S – Should have – important requirements that could be omitted
C – Could have – optional requirements
W – Want to have – the requirements really can wait

6. Interviewing and questionnaires
Interviewing: synchronous elicitation technique
Questionnaires: asynchronous elicitation technique
Based on:
Ask questions and listening/reading the answers
Be prepared to ask follow-up questions
Ask for documents you need
Log the answers (to support, complete or contradict what was said/written)
Involve all the stakeholders

7. Viewpoints
Viewpoints permits us to classify stakeholders and other sources of requirements
Multi-perspective analysis / diversity of source of information are important
3 categories of viewpoints
Interactor viewpoints: People or other systems that interact with the system
Indirect viewpoints: Stakeholders who do not use the system directly but who influence the requirements in some ways
Domain viewpoints: Domain characteristics and constraints

8. Viewpoints More specific viewpoints:
Providers and receivers of system services
Systems interfacing with the new system
Regulations and standards applying to the system
Sources of business and non-functional requirements
Engineering viewpoints: developing, managing, maintaining the system
Marketing viewpoints

9. The VORD method
This method implements a viewpoint-oriented approach for requirements elicitation
VORD = Viewpoint Oriented Requirements Definition
It is based on:
Viewpoint identification
Discovering the viewpoints, services and constraints
Viewpoint structuring
Allocating services to viewpoints
Viewpoint data/control
Group the viewpoints into a hierarchy
Viewpoint documentation
Refine the description of the viewpoints, services and constraints
Use of a template
Viewpoint system mapping
Transform the analysis to an object-oriented design

10. VORD template

11. Example: ATM
Viewpoint identification

12. Example: ATM
Viewpoint structuring: Allocating services to viewpoints

13. Example: ATM
Viewpoint structuring: Viewpoint data/control

14. Example: ATM
Viewpoint structuring: Viewpoint hierarchy

15. Example: ATM
Viewpoint documentation

16. Scenarios
If it often easier for people to relate on real-life example rather than abstract statements
Scenarios are descriptions – sequences of events - of how the system is used in practice.
Scenarios are composed of:
A description of the initial state of the system
A description of the normal flow of events in the scenario
A description of what can go wrong and how it is handled
Information on other activities that might be going on concurrency
A description of the final state of the system

17. Use cases
Use cases are a scenario-based technique for describing requirements
Use cases identify the users of the system (actors)
Use cases identify the tasks (use cases)
Use cases relate the users and the tasks
Use cases are typically illustrated with UML as stick figures or similar diagrams
A set of use cases should describe all possible interactions with the system
Use cases are more effective in capturing functional requirements

18. Example: Flights reservation system

19. Use-cases relationships
Use cases have relationships
Inclusions:
A use case contain the behavior from another use case (unconditional)
Can be seen as a factorization
Introduced by the <<include>> keyword
Extensions:
A use case conditionally interrupts the execution of another use case to augment its functionality
An extension point may specify a precondition for the extending behavior
Introduced by the <<extends>> keyword
Inheritance

20. Flights reservation system

21. Requirements specification
Examples of templates (Available in the Blackboard):
Microsoft template. Karl E. Wiegers. Software Requirements. Windows Press.
Volere template

22. Textual descriptions of a use-cases
The textual description of a use case includes:
Use case ID
Use case name
Actors
Description
Pre-condition
Post-condition
Normal course
Alternative course
Exceptions
Includes
Priority
See also template of Karl E. Wiegers, Microsoft

23. Requirements validation
Requirements must be checked for:
Validity, comprehensibility, traceability (source, dependency between requirements) consistency, completeness, realism and verifiability
Validation techniques:
Requirements reviews
Expert review, two independent reviews
Formal/informal
Involvement of the stakeholders necessary
Test-case generation
Tests are developed for the requirements
Prototyping
Mini-definitions of the requirements
A team redefine the requirements and compare them with the list of produced requirements
There are lots of validation techniques (more than 21). Dr. Goldsmith’s presentation.

24. Requirements management
Requirements management deals with the process of managing changes in the requirements during the requirements engineering process and system development
Requirements traceability is concerned with the relationships between requirements (dependencies), their sources and the system design
CASE tools are necessary for the requirements storage and management

25. Traceability matrix
A traceability matrix permits us to see the relationships/dependencies between requirements
U: Uses
W: Weak relationship