CS 179 A Brief Review of Requirements Engineering Dr Eamonn Keogh

1. CS 179 A Brief Review of Requirements Engineering Dr Eamonn Keogh Computer Science & Engineering DepartmentUniversity of California - RiversideRiverside,CA 92521eamonn@cs.ucr.edu

2. Requirements Engineering Definition: Establishing what the customer requires from a software system. A process in which “what is to be done” is elicited, modeled and communicated. This process has to deal with different viewpoints, and it uses a combination of methods, tools and actors. The product of this process is a model, from which a document, usually a requirements definition is produced [1]. [1] Leite, J.C.S.P, Freeman, P. A. Requirements Validation Through Viewpoint Resolution IEEE Transactions on Software Engineering: Vol. 17, N. 1, pp: 1253 -- 1269, (1991). Extreme Requirements (XR) 13

3. Horror Stories I Adapted from Dr Michael Blacks Course Notes, used with permission • The Standish Group describes 3 categories of projects. • Success (16.2%) • Delivered fully functional and on time • Challenged (52.7%) • Deliver less than full functionality, over-budget, late • Impaired (31.1%) • Canceled during development

4. Horror Stories II Adapted from Dr Michael Blacks Course Notes, used with permission 28% of projects exhibit cost overruns of 150% or more The same 28% pf projects exhibit time reruns of 200% or more Many projects start with the wrong goals and need to restart (94% of projects need to restart).

5. Horror Stories III • Where the money goes…. • Most money is spent on testing and maintaining systems. • 85% of the errors are made at the requirements analysis phase. • Consider software costs by development phase: • Requirements 3% • Design 8% • Programming 7% • Testing 15% • Maintenance 67% • 85% of the errors are in the requirements phase, yet only 3% of the time/money is spent there!!

6. Why is Requirements Engineering Important? • It helps earlier detection of mistakes, which will be much more costly to correct if discovered later. • It forces clients to articulate and review requirements and supports agreement among developers and customers. • It records and refines requirements, helps understanding of design rationales, enhances communications. • It serves as a standard against which to test design and implementation for correctness and completeness. • It supports project management, e.g. resource estimation (cost, personnel, skill, equipment, ..). • It boosts confidence among developers.

7. Requirements Engineering consists of… • (These parts can be named or structured differently by different approaches) • Requirements definition(This should be a more complete version of the “proposal” you handed in) • A statement in natural language plus (optionally) diagrams of the services the system provides and its operational constraints. • Requirements elicitation • The process by which you find out what the customer really wants. • Requirements specification • A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor. (You are required to have me sign this before doing any coding or design).

8. Requirements definition(This should be a more complete version of the “proposal” you handed in) • A statement in natural language plus diagrams of the services the system provides and its operational constraints. • This document should be as implementation independent as possible. • A useful idea is to have some user scenarios. These are examples of how people interact with the system. • Tom, a 22 year old computer whiz, wants to find out… using a slow connection… • Sue, a 85 year old…., from a local library with a fast…

9. Requirements elicitation • The process by which you find out what the customer really wants. (Stakeholder analysis, Interviewing, Study similar companies, Observation, Task demonstration, Document studies, Questionnaires, Brainstorming, Focus groups, Domain workshops, Design workshops, Pilot experiments, Ask suppliers, Negotiation, Risk analysis, Cost/benefit analysis, Goal-domain analysis, Domain-requirements analysis). • You need to come up with a plan to do the Requirements elicitation, and then document every step of the plan. At an absolute minimum... • We decided to do “Interviewing” and “Study similar… …we did a practice interview run with one member of our group posing as the client… we researched the domain by…we came up with a list of questions to ask the client… we came up with 10 scenarios to discuss with the client… after the interview we recorded the following notes… we summarized the notes here… we sent a copy of the notes to the client on this date and invited him to comment on them…we.. • The above should be in a neat, organized document (I suspect that it will require at least 6 pages.)

10. Requirements specification I • A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor. You are required to have me sign this before doing any coding or design. • A requirements specification must be • Correct • Complete • Unambiguous • Verifiable • Traceable • Design Independent • Comprehensible • Modifiable • Consistent, Concise, Organized. • I can imagine this being well done in anything less than 8 pages. It is NOT a design document!! As far as possible, it should set out WHAT the system should do rather than HOW it should do it.

11. Requirements specification II • Specify external system behavior. • Specify implementation constraints. • Serve as reference tool for maintenance. • Record forethought about the life cycle of the system i.e. predict changes. • Characterize responses to unexpected events.

12. Requirements specification III • One possible model… • Introduction • Describe need for the system and how it fits with business objectives • Glossary • Define technical terms used • System models • Define models showing system components and relationships • Functional requirements definition • Describe the services to be provided • Non-functional requirements definition • Define constraints on the system and the development process • System evolution • Define fundamental assumptions on which the system is based and anticipated changes • Requirements specification • Detailed specification of functional requirements • Appendices • System hardware platform description

13. What to do now!! • If you have not done so, hand in your proposal within 24 hours • Make an appointment for your group to meet me or the TA and do some requirements elicitation (in the next seven days). (plan your requirements elicitation before seeing me). • Begin requirements specification, have a high quality draft in the next two weeks.

14. Links and references http://www.cs.toronto.edu/~sme/CSC2106S/03-ElicitationI.pdf http://www.cs.toronto.edu/~sme/CSC444F/slides/L14-RequirementsAnalysis.pdf http://www.cs.toronto.edu/~sme/CSC2106S/index.html Goguen, J., & Linde, C. (1993). Techniques for Requirements Elicitation. Proceedings, First IEEE International Symposium on Requirements Engineering (RE'93) San Diego, California, USA, pp. 152-164. IEEE Computer Society Press.