1. What are Requirements?

2. "The hardest single part of building a system is deciding what to build... No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." -- Fred Brooks

3. Product Engineering

4. Definitions Software Requirements  Descriptions of the services and constraints of a software system  Tells what to build, not how to build it. Why Spend a Lot of Time? Requirements are the source for all future steps in the software life cycle  Lays the basis for a mutual understanding Consumer (what they get) Software producer (what they build)  Identifies fundamental assumptions  Potential basis for future contracts Better get it right - u pon delivery, some software is rejected by customers Changes are cheap - b etter make them now rather than later

5. Types of Requirements Functional vs. Non-functional vs. Domain Reqs  Focuses on the visible and invisible features of the software system and the constraints intrinsic to its application space User vs. System Requirements  Focuses on the User or the System perspective FunctionalNon-functional UserMost user reqs are specified as functional End users do not typically specify; come out of analysis SystemSystem-level standards, such as standard GUI Many such reqs may be specified here

6. Functional requirements Describe functionality or system services  Depend on the type of software, expected users and the type of system where the software is used  Functional user requirements are high-level statements of what the system should do but functional system requirements should describe the system services in detail Examples  “The user shall be able to search either all of the initial set of databases or select a subset from it.”  “The system shall provide appropriate viewers for the user to read documents in the document store. “  “Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.”

7. Non-functional requirements Define system properties and constraints  e.g. reliability, response time and storage requirements  Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method Non-functional requirements may be more critical than functional requirements.  If not met, the system is useless

8. Non-functional classifications Product requirements  Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.  Example: “4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set ” Organisational requirements  Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.  Example: “9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo- SP-STAN-95” External requirements  Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.  Example: “7.6.5 The system shall not disclose any personal information about customers apart from btheir name and reference number to the operators of the system”

9. Non-functional requirement types

10. User vs. System Requirements User requirements  Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers  Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge  User requirements are defined using natural language, tables and diagrams System requirements  A structured document setting out detailed descriptions of the system services. A contract between client and contractor  More detailed specifications of user requirements  Serve as an initial basis for designing the system

11. Domain requirements Derived from the application domain and describe system characteristics and features that reflect the domain  May be new functional requirements, constraints on existing requirements, or define specific computations  If domain reqs are not satisfied, the system may be unworkable  Typically elicited from domain experts (doctors, lawyers, etc.) or domain-specific standards documents (procedures). Problems  Understandability Requirements are expressed in the language of the application domain This is often not understood by software engineers developing the system  Implicitness Domain specialists understand the area so well that they do not think of making the domain requirements explicit Examples:  “Patient information modules must conform to the HL-7 data standards”  “The eLearning delivery platform must be ADA-508 compliant”

12. Requirements Examples Specify whether the following are  Functional, Nonfunctional, and/or Domain If nonfunctional, are they Product, Organizational, or External?  System or User 1. “The user shall be able to toggle between displaying and hiding all HTML markup tags In the document being edited with the activation of a specific triggering mechanism.” 2. “The online credit-card payment facility shall support a minimum of 1000 credit-card transactions per hour”. 3. “The doctor shall be able to search the patient tracking system for similar symptoms By typing keywords into a dialog box on the application’s main web page.” 4. “The XML-based content management system shall support UTF-8 encoding” 5. “The system shall be up and running 99.9999% of the time”. 6. “The system shall support the EDI standard for medical patient data exchange” 7. “The user shall save files by selecting the’File  Save’ menu choice”

13. Other Requirements Classifications Change is a Risk!  The priority of requirements from different viewpoints changes during the development process  System customers may specify requirements from a business perspective that conflict with end-user requirements  The business and technical environment of the system changes during its development Enduring requirements  Stable requirements derived from the core activity of the customer organisation.  e.g. a hospital will always have doctors, nurses, etc.  May be derived from domain models Volatile requirements  Requirements which change during development or when the system is in use.  e.g. In a hospital, requirements derived from health-care policy

14. Summary Requirements are the representation of what the customer wants not how you will implement it. Requirements can be classified several ways:  Functional vs. Non-functional  User vs. System  Domain-specific vs. domain-independent  Enduring vs. Volatile Requirements can be annotated to help manage change Dr. Gary’s tip: Annotate your features and requirements!!!  For each feature/requirement, note the classification above  For each feature/requirement, annotate in as many ways that are useful to managing the scope of impact when they change

15. Requirements Checklist Example Attribute ValuesDescription 1.Verifiable Yes/No Can you (did you) write a test to check for it? 2.Traceable GUID Assign a unique identifier to the feature/req 3.Volatility %0% = Enduring, 100% = (very) Volatile 4.Behavioral Funct/NF if NF, classify (slide 7-8, WhatAreReqs slides 5.Perspective User/System 6.Domain-specific Yes/Noif Yes, describe source 7.Priority High/Med/LowLater you can use “scale of 1 to 10” or biz value Example: REQVTVol.BPDPriNotes R1NoBN010%FUYLStable; but need a test R2YesXYZ150%FUNMWorried user may change mind R3No80%NF-OrgSNHWe don’t understand at all!