Software Requirements and the Requirements Engineering Process

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 2004. (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 • http://www.volere.co.uk

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