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

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

3. PVK-063 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: oFunctional Requirements oNon functional requirements

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

5. PVK-065 Non-Functional Requirements Non functional requirements are properties or qualities the product must have. Product qualities: oUsability oEfficiency Performance Space oReliability oPortability o Cultural and political o Legal requirements o....

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

7. PVK-067 Acquire and identify requirements oStudy the system / organisation oStudy available documents oAsk users / domain experts Questionnaires Interviews Analyse and evaluate requirements oDomain analysis oPrototyping oJAD / JAW oScenario modelling Document requirements Review and validate requirements RE Activities

8. PVK-068 Describe system behaviour oFunctional requirements oUser interface oAcceptable responses to undesired events Describe system properties oNon-functional requirements oAcceptance criteria Implementation independent reference Specifies the WHAT and not the HOW Part of the contract between customer and developer Purpose of the Requirements Document

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

10. PVK-0610 Format of a Requirements Document  Problem  Background information  Operational Environment  Functional Requirements  Non-functional requirements  Constraints Volere Requirements Specification Template http://www.systemsguild.com/GuildSite/Robs/Template.html

11. PVK-0611 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 in understanding Explain all of your terminology Use “shall,” “must,” “should,” consistently

12. PVK-0612 Problems with NL specification Ambiguity oThe 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 oThe same thing may be said in a number of different ways in the specification. Lack of modularisation oNL structures are inadequate to structure system requirements.

13. PVK-0613 Alternatives to NL specification

14. PVK-0614 Form-based node specification

15. PVK-0615 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 Actor Use Case

16. PVK-0616 Use Case Diagram Sign on for exams Take exam Student SecretaryDeanStudent Administer marks Schedule lectures Prof

17. PVK-0617 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 oNew requirements emerge during the process as business needs change and a better understanding of the system is developed; oDifferent viewpoints have different requirements and these are often contradictory.