Comprehensive Requirements Engineering Guide

1. Contents • Introduction • Requirements Engineering • Project Management • Software Design • Detailed Design and Coding • Quality Assurance • Maintenance

2. Requirements Engineering • What is a Requirement? • Functional, non functional requirements • RE Activities • Requirements Documentation • RE Notations • Requirements management

3. What is a Requirement? • A Requirement is something that the product must do or a quality that the product must have. • Two kinds of requirements: • Functional Requirements • Non functional requirements

4. Describe what the system should do What inputs the system should accept What outputs the system should produce What data the system should store that other systems might use What computations the system should perform The timing and synchronization of the above Functional Requirements

5. Non functional requirements are properties or qualities the product must have. Product qualities: Usability Efficiency Performance Space Reliability Portability Non-Functional Requirements • Cultural and political • Legal requirements • ....

6. System shall communicate with external system X. The product shall run on the company’s existing Unix machines. The system shall provide appropriate viewers for the user to read documents in the document store. The product should be user friendly..... Examples Functional Non functional Functional Non Functional .....new users should be able to add buttons within 30 minutes of their first attempt at using the product.

7. RE Activities • Acquire and identify requirements • Study the system / organisation • Study available documents • Ask users / domain experts • Questionnaires • Interviews • Analyse and evaluate requirements • Domain analysis • Prototyping • JAD / JAW • Scenario modelling • Document requirements • Review and validate requirements

8. Purpose of the Requirements Document • Describe system behaviour • Functional requirements • User interface • Acceptable responses to undesired events • Describe system properties • Non-functional requirements • Acceptance criteria • Implementation independent reference • Specifies the WHAT and not the HOW • Part of the contract between customer and developer

9. Requirements xxxx xxxxxxx xxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx subsystem 1 subsystem 2 Requirements Requirements Definition xxxx xxxxxxx xxxx xxx xxxxxxx Requirements xxxxxxxxxxx xxx xxxxx Specification xxxxxxxxxxx xxxxxxxxxxxxx xxxxx xxxxxxx xxxx xxxxxxxxxxxxx xxx xxxxxxx xxxxxxx xxxxxxxxxxxxxxx xxx xxx xxxxxxxxxxx xxxxxxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx sub-subsystems xxx xxxxxxxxxxxxxxx Requirements Requirements Requirements Requirements Definition Definition Definition Definition xxxx xxxx sub-subsystems xxxx xxxxxxx xxxx xxxxxxx Requirements xxxxxxx xxx xxx Requirements xxxxxxx Requirements xxx xxxxxxxxxxx xxx xxxxxxxxxxx Requirements Specification xxxxxxxxxxx xxxxx Specification xxxxxxxxxxx Specification xxxxx xxxx Specification xxxxx xxxxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxx xxxx xxxxxxx xxxxxxxxxxxxx xxxxxxx Requirements xxxxxxxxxxxxx xxxx xxxxxxx xxxxxxx xxxxxxx xxx Requirements xxxxxxx xxx xxxxxxx xxxxxxx xxx xxx xxx xxxxxxxxxxx Definition xxx xxxxxxxxxxxxxxx Definition xxx xxx xxxxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxxxx xxxx xxxxxxxxxxxxxxx xxxxxxxxxxx xxxxx xxxxx xxxxxxxxxxxxx xxxx xxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxx xxxxxxx xxx xxxxxxxxxxxxx xxxxxxx xxx Requirements xxxxxxx xxx xxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxx xxx xxxxxxxxxxxxxxx xxxxx Specification xxx xxxxxxxxxxxxxxx xxxxx xxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxxxxxx xxxx xxxxxxx xxxxxxx xxxxxxx xxx xxx xxx xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxxxx xxxxx xxxxxxxxxxxxx xxxxxxx xxx xxxxxxxxxxxxxxx Types of Requirements Document • Two extremes: • An informal outline of the requirements using a few paragraphs or simple diagrams • requirements definition • A long list of specifications that contain thousands of pages of intricate detail • requirements specification Requirements documents for large systems are normally arranged in a hierarchy Requirements Requirements Definition Definition xxxx xxxx xxxxxxx xxxxxxx Requirements xxx xxx Requirements Requirements xxxxxxxxxxx xxxxxxxxxxx Specification xxxxx Specification Specification xxxxx xxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxx xxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxx xxx xxx xxx xxx xxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxxxx xxxxxxxxxxx xxxxx xxxxx xxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxxxxxxxx xxxxxxx xxxxxxx xxxxxxx xxx xxx xxx xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx

10. Requirements Writing Style Do not use vague terms or verbs like “some,” “obviously,” “usually,” “often,” “it follows that,” … Make sure that uncompleted lists are understood completely (e.g. “etc.,” “and so on,”“…,” ...) Make sure that ranges are clearly understood, e.g. what means “in the range of 1 to 100” Ask for clear definitions of terms like “always,” “never,” “almost,” etc. Use pictures and examples to aid inunderstanding Explain all of your terminology Use “shall,” “must,” “should,” consistently

11. Problems with NL specification • Ambiguity • The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. • Over-flexibility • The same thing may be said in a number of different ways in the specification. • Lack of modularisation • NL structures are inadequate to structure system requirements.

12. Alternatives to NL specification

13. Form-based node specification

14. Use Case Modelling • Actor: external person, organization, or system communicating with the system (data exchange) • System boundary: Collection of all use cases • Use case: action that is triggered by an actor or produces a result for an actor • Use case description: textual or semi-formalized description of a use case content Use Case Actor

15. Secretary Dean Student Prof Use Case Diagram Sign on for exams Take exam Student Administer marks Schedule lectures

16. Requirements Management • Requirements management is the process of managing changing requirements during the requirements engineering process and system development. • Requirements are inevitably incomplete and inconsistent • New requirements emerge during the process as business needs change and a better understanding of the system is developed; • Different viewpoints have different requirements and these are often contradictory.