1. IS550: Software requirements engineering Dr. Azeddine Chikh 1. Introduction and basic concepts

2. Soren Lauesen, "Software Requirements: Styles & Techniques" Addison-Wesley Professional 2002, 608 pp, ISBN- 10: 0201745704 - ISBN-13: 9780201745702 Text

3. Contract Analysis Reqspec Op & maint Design Program Test Demands Elicitation Stakeholders Verification Validation Tacit demands & reqs Tracing: Forwards... Backwards... Req. management: Changing reqs 1. The role of requirements 3

4. Tacit demands : are necessary – we cannot specify everything Elicitation and analysis : finding and structuring requirements Validation: the customers check that requirements match demands Verification: checking that the product fulfills the requirements 4

5. 1. The role of requirements Tracing : is needed to compare requirements against other information. There are 4 types of tracing Forward: Tracing from requirements to program Tracing from demands to requirements Backward: Tracing from program to requirements Tracing from requirements to demands 5

6. 1. The role of requirements Req. management : in spite of attempts to get it right the first time requirements change during development. It must be easy to update the specification, add new requirements, and asses the consequences of change. 6

7. 2. Project types There are many types of project: in-house development buying commercial software tenders and contracts, etc. Requirements have different roles in different types of projects Sometimes the project type is unknown 7

8. 2. Project types Project typesCustomerSupplier In-houseUser dept.IT dept. Prod. devel.MarketingSW dept. Time & materialsCompanySW house COTSCompany(Vendor) TenderCompanySupplier Contract devel.CompanySW house Sub-contractingSupplierSW house Unknown Inhouse? COTS? 8

9. 2. Project types In-house development : The system is developed inside a company for the company’s own use. The customer and the supplier are departments of the same company Larger companies: banks, insurance comp., … Product development : The product is a commercial software to be marketed by a company The development project is carried out inside the company. The customer is the marketing department and the supplier the development department 9

10. 2. Project types Time and materials based development: A software house develops the system on a time-and- materials base, i-e the customer pays the costs, for instance month by month Requirements are informal (unwritten) and develop over time Over time, the parties tend to realize that such projects can easily get out of control. COTS purchase: Commercial Off The Shelf that we can buy from the market (more or less off the shelf) : MS-Office, development tools, hospital and bank systems We distinguish COTS purchase (fully off the shelf) from COTS based (including some tailor-made configuration or extension) 10

11. 2. Project types Tender: The costumer company starts a tender process and sends out a request for proposal (RFP). Several suppliers are invited to submit proposals The tender documentation contains an elaborate requirement specification The customer selects the best proposal Contract development: A supplier company develops or delivers a system to the customer company. The requirements specification and the contract specify what is to be delivered The two parties will often work together for some time to write the requirements and the contract. The system may be tailor-made or a COTS-based system with extensions 11

12. 2. Project types Sub-contracting: A subcontractor develops or delivers part of the system to a main contractor, who delivers the total system to a customer. Sub-contracting can be requirements-based or time-and-materials based without written requirements Situation unknown: In many cases the customer doesn’t know what should do. Should he buy a COTS system or have the system developed in-house ? Should he try to integrate several products or should he contract with someone else to do it? High-level requirements can help to resolve these issues. They may help compare the alternatives from a cost/benefit and risk perspective. 12

13. 3. Contents of ReqSpec Functional requirements, each interface: Record, compute, transform, transmit Theory: F(input, state) -> (output, state) Function list, pseudo-code, activity diagram Screen prototype, support tasks xx to yy System Platform: HW, OS, DB Spreadsheet Ext. products: Sensors, dev. Special SW User groups Quality reqs: Performance Usability Maintainability... Other deliverables: Documentation Install system Convert data Train users... Managerial reqs: Delivery time Legal Intellectual properties Development... Helping the reader: Background (Rationale) Business goals Definitions Diagrams... Organizing the parts: Best-known standard : IEEE 830 Interfaces Data requirements: System state: Database, comm. states Input/output formats 13

14. 4. Problems observed in practice Relatively few problems in data and functional requirements Serious problems ensuring efficient task support and meeting business goals Quality requirements : important, but what should be written ? Parts to help the reader : important, but often ignored 14

15. 4. Problems observed in practice Roster planning, Midland Hospital (old project) R47.It must be possible to attach a duty type code (first duty, end duty, etc.) to the individual employee. R144.The supplier must ensure that pay tables are updated no later than a month after new collective agreements,... R475.The system must be able to calculate the financial consequences of a given duty roster - in hours and in money terms. Prevent R479.The system must give notice if a duty roster implies use of a temporary worker for more than three months. R669.The system must give understandable messages in text form in the event of errors, and instruct the user on what to do. User tasks supported? Business goals obtained? 15

16. 5. Domain and product level Product : the system to be delivered Product-level requirements : specify what should come in and out of the product. Domain : the product and its immediate users and other surroundings Domain-level requirements : describe the activities that go on outside the product – in the domain. The req. are to support those activities Quality req. can be at a product level as well as at a domain level. Example :performance 1: Product level : response time for the computer system (1) 2 : Domain level : performance time for a user task = manual time + (1) Clients : people served by the domain System : the product, the domain, or software plus hardware ? 16

17. Product Platform Control computers User activities Domain I/O Product I/O Domain Clients “Business” domain Actors? Elevators Product-level reqs: The product shall accept the following input:... Domain-level req: The product shall support the following user activities:... 5. Domain and product level 17

18. 5. Domain and product level Redefined limits Product Control computers User activities Domain Clients “Business” domain 18

19. 6. The goal-design scale A requirement must specify what the system should do without specifying how. Goal-level requirement : why the customer wants to spend money on the product Domain-level requirement : supports user tasks xx to yy Product-level requirement : a function to be provided by the product Design-level requirement : details of the product interface 19

20. 6. The goal-design scale R1. Our pre-calculations shall hit within 5% R2. Product shall support cost recording and quotation with experience data R3. Product shall have recording and retrieval functions for experience data R4. System shall have screen pictures as shown in app. xx Goal-level requirement Domain-level requirement Product-level requirement Design-level requirement Which requirement to choose? If the supplier is A vendor of business applications? A software house - programmers? PriceWaterhouseCoopers? 20

21. 6. The goal-design scale Neural diagnostics System shall have mini keyboard with start/stop button,... Why? Possible to operate it with “left hand”. Why? Both hands must be at the patient. Why? Electrodes, bandages, painful... Ask “why” 21

22. 6. The goal-design scale In general it is an advantage to include “business” goals’, domain descriptions and - using more caution - examples. Recommendations : Why+ How Measuring neural response is a bit painful to the patient. Electrodes must be kept in place... So both hands should be at the patient during a measurement. R1:It shall be possible to perform the commands start, stop,... with both hands at the patient. Might be done with mini keyboard (wrist keys), foot pedal, voice recognition, etc. Domain - why Req. Example - how 22

23. 7. Typical project models Product-level requirements : elicited from users. A lot of work Domain-level requirements : describe user tasks. Much faster. Two-step approach : domain-level first, design-level later with careful checks Contracts and price structure : can reduce risks. 23

24. 7. Typical project models Traditional: Product-level reqs Ask users, study documents,... extract features/functions. Intro, [business goals]... System limits, e.g. context diagram Data reqs, e.g. data model, data descr. Product-level funct. reqs, e.g. features Critical quality reqs Fast approach: Domain-level Describe user tasks, study documents... Intro, [business goals, BPR tasks]... System limits, e.g. context diagram Data reqs, e.g. verbal data descr. Domain-level reqs, e.g. Tasks & Support [Trace analysis: goals to tasks] Critical quality reqs Two-step approach: Domain-level + design-level All the fast-approach stuff + Design-level reqs, e.g. prototypes, comm.protocols Approaches 24

25. 7. Typical project models Recommended project models Project type:Trad.DomainTwo-step In-house?OKOK Product dev.?OK Time & mat.?OKOK COTS business?OK COTS toolsOK Tender COTS?OK Tender tailor?OK  OK  Contract COTS?OK Contract tailor?OK  OK  Sub-contractOKOK MaintenanceOK  Variable price ? Used, but dubious Project model 25

26. 7. Typical project models Contracts and prices Contract typeAnalysisDesignProgram Analysis only Design & dev. All-in-one Development 26