1. Slide 1 CS 310 Ch 6: Software Requirements Requirements engineering: establishing the services that the customer requires from a system and the constraints under which it operates and is developed Requirements: descriptions of the system services and constraints that are generated during requirements engineering

2. Slide 2 Hypothetical Problem: set up a Software Assistance Center What are the requirements? are we thinking the whole system or just the programming Is there any organization to this? How would you present this to Dean Miller-Bernal? How would you present this to someone who will build it?

3. Slide 3 What is a requirement? What the system should do, not how what: maintain student grades how: store student grades in a MySQL database with web front-end Range: a high-level abstract statement of a service or of a system constraint a detailed mathematical function (how grades are calculated) Inevitable since requirements may be the basis for a bid - therefore open to interpretation be the basis for the contract - therefore detailed Both may be called requirements Our goal: make them as specific as possible

4. Slide 4 Levels of requirement User requirements statements in natural language plus diagrams of the services the system provides and its operational constraints–written for system users who don’t have detailed technical knowledge problems »lack of clarity: precision can make the document difficult to read »requirements confusion: functional and non-functional mixed-up »amalgamation: several different requirements lumped together System requirements (more detailed than user requirements) a structured document setting out detailed descriptions of the system services may be used as part of the system contract serves as a basis for building the system and for acceptance testing Don't separate these in your project, aim for a complete, detailed document

5. Slide 5 User versus system requirement Comment: I don’t make this distinction. A spec should contain the details. System requirements specification 1.1 The system will store grades for each student enrolled in CS 10x 1.2 These grades will be retained for 5 years 1.3 TAs must logon to enter or change student grades 1.4 TAs may change grades only in courses to which they have been granted permission 1.4 The system will log each change to a grade 1.5 A student must logon and can see only grades in courses she is taking 1.6 The system will log each failed login attempt User requirement definition 1 The system will allow TAs to enter grades for each student in CS 10x 2 The system will allow students to check their current grade

6. Slide 6 6.1 Functional and non-functional requirements Functional services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations the system will allow TAs to enter grades for each student in CS 10x Non-functional constraints on the system services such as timing constraints, constraints on the development process, standards, etc. the system will be available 24/7 Domain requirements that come from the application domain of the system and reflect characteristics of that domain e.g. the laws of physics e.g. how grades are calculated

7. Slide 7 Non-functional requirements * * How the product must behave

8. Slide 8 Examples Product requirement all communication between the system and the user shall be transferred in XML Organizational requirement the system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-05 External requirement the system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system

9. Slide 9 Requirements measures

10. Slide 10 Back to the Software Assistance Center How about these? it will be staffed by smart people they will answer questions it will be open a lot the room will be nice Do: email me 5-10 representative functional and non functional requirements

11. Slide 11 So, how do we write specifications? Natural language ambiguous over-flexible (one can say the same thing may be said several ways) lack of modularization Alternatives -various more formal notations structured natural language (my favorite) using a standard form using a program design language (PDL)

12. Slide 12 Structured NL specification

13. Slide 13 Form-based node specification

14. Slide 14 Sequence diagram of ATM withdrawal

15. Slide 15 PDL interface description

16. Slide 16 6.5 Software requirements document The official statement of what the developers must build Not a design document. As far as possible, it describes what the system should do, not how what: maintain author, title, and price in a database how: store author, title, and price at locations x-y It should be easy to read/change the basis for system design the basis for system testing a reference tool for maintenance (NO) forethought about the system life cycle (NO, only as requirements)

17. Users of a requirements document no

18. Slide 18 Guidelines for writing requirements Use a standard format for all requirements Use language consistently. Use “shall” for mandatory requirements, “should” for desirable requirements (I don't believe "desirable" requirements belong) Avoid computer jargon Be concise remove extra words do not cover a requirement more than once Avoid ambiguity

19. Slide 19 Exercise Rewrite the following requirements so that they may be objectively validated. You may make any reasonable assumptions about them. The software system shall provide acceptable performance under maximum load conditions The system interface shall use a character set as available on the standard terminal If the system fails in operation, there should be a minimal loss of data The software development process used shall ensure that all of the required reviews have been carried out The software will be well-written The software must be developed in such a way that it can be used by inexperienced users

20. Slide 20 Requirements document structure Introduction: describe need for the system and how it fits with business objectives System models: define models showing system components and relationships Functional requirements: the services to be provided Non-functional requirements: constraints on the system and the development process Appendices. e.g. glossary: define technical terms used system hardware platform database requirements (as an ER model perhaps) This differs somewhat from the text