ICS 52: Introduction to Software Engineering

1. ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Topic 4 Partially based on lecture notes written by Sommerville, Richard N. Taylor, André van der Hoek, Dan Frost and Doris Tonne. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

2. Today’s Lecture • Requirements Engineering • Components of a Requirements Document

3. Requirements engineering • “The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed” [sommerville] • What is a Requirement? • It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification

4. Requirements Engineering Processes • Processes used to discover, analyse and validate system requirements

5. Requirements engineering processes • The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements • However, there are a number of generic activities common to all processes • Requirements elicitation • Requirements analysis • Requirements validation • Requirements management

6. The Requirements Engineering Process

7. RE Process • A feasibility study decides whether or not the proposed system is worthwhile • Can it be done within the constraints? • Elicitation and Analysis • What is the application domain? • What are the constraints • Should involve all stakeholders • End users, Managers, engineers • Domain experts, unions etc..

8. Problems of requirements analysis • Stakeholders don’t know what they really want • Stakeholders express requirements in their own terms • Different stakeholders may have conflicting requirements • Organisational and political factors may influence the system requirements • The requirements change during the analysis process. New stakeholders may emerge and the business environment change

9. Requirements Specification • Specify only external system behavior • Specify constraints on implementation • Easy to change • Serve as a reference during maintenance • Record forethought about system lifecycle • Characterize responses to undesired events

10. Users of a Requirements Document

11. Introduction Executive summary Application context Functional requirements Environmental requirements Software qualities Other requirements Time schedule Potential risks Future changes Acceptance Test Plan Glossary Reference documents Structure

12. Introduction • What is this document about? • Who was it created for? • Who created it? • Outline

13. Executive Summary • Short, succinct, concise, to-the-point, description • Usually no more than one page • Identifies main goals • Identifies key features • Identifies key risks/obstacles

14. Application Context • Describes the situation in which the software will be used • How will the situation change as a result of introducing the software? • “World Model” • Identifies all things that the system affects • Objects, processes, other software, hardware, and people • Provides an abstraction for each of those, characterizing the properties and behaviors that are relevant to the software system • Identifies fundamental assumptions & Likely Changes

15. Functional Requirements • Describe functionality or system services • Identifies all concepts, functions, features, and information that the system provides to its users • Provides an abstraction for each of those, characterizing the properties and functions that are relevant to the user • What is the system supposed to do? • What information does the system need? • What is supposed to happen when something goes wrong? An approximate user interface is part of functional requirements

16. Examples of Functional Requirements • 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.

17. Requirements imprecision • Problems arise when requirements are not precisely stated • Ambiguous requirements may be interpreted in different ways by developers and users • Consider the term ‘appropriate viewers’ • User intention - special purpose viewer for each different document type • Developer interpretation - Provide a text viewer that shows the contents of the document

18. 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. • Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless • Environmental, performance, Qualities, and other Requirements

19. Non-Functional Requirement Types

20. Goals and requirements • Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. • Goal • A general intention of the user such as ease of use • Verifiable non-functional requirement • A statement using some measure that can be objectively tested • Goals are helpful to developers as they convey the intentions of the system users

21. Examples • A system goal • The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised. • A verifiable non-functional requirement • Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

22. Requirements measures

23. Environmental & Performance Requirements • Environmental • Platforms • Operating Systems • Hardware: types of machines, memory size, hard disk space • Software • CORBA, Jini, DCOM, 4GL, … • Programming language(s) • Performance • Speed ( system response)

24. Correctness Reliability Robustness Performance User friendliness Verifiability Maintainability Repairability Safety Evolvability Reusability Portability Understandability Interoperability Productivity Size Timeliness Visibility Software Qualities

25. Other Requirements • What about cost? • What about documentation? • What about manuals? • What about tutorials? • What about on-the-job training? • What about requirements that do not fit in any of the previous categories?

26. Time Schedule • By when should all of this be done? • Initial delivery date • Acceptance period • Final delivery date • What are some important milestones to be reached? • Architectural design completed • Module design completed • Implementation completed • Testing completed

27. Potential Risks • Any project faces risks • Boehm’s top ten risks (see Topic 2) • It is important to identify those risks up-front so the customer and you (!) are aware of them • One of the requirements could be to explicitly address the risks

28. Future Directions and Expected Changes (aka Lifecycle Considerations) • Any project faces changes over time • Identify up front • Awareness • planning • Future Enhancements • One of the requirements could be to build the product such that it can accommodate future changes

29. Future Directions and Expected Changes (aka Lifecycle Considerations) • Serve as basis for future contracts, new versions • Reduce future modification costs • Identify items likely to change • Identify fundamental assumptions • Structure document to make future changes easy • e.g. have a single location where all concepts are defined

30. Acceptance Test Plan • Part of the requirements specification • An operational way of determining consistency between the requirements specification and the delivered system • If the system passes the tests demanded by this plan, then the buyer has no (legal, moral) basis for complaint • Develop a plan for testing all aspects of the requirements specification • e.g. Functional properties, performance, adherence to constraints

31. Glossary • Precise definitions of terms used throughout the requirements document

32. Reference Documents • Pointers to existing processes and tools used within an organization • Pointers to other, existing software that provide similar functionality • Pointers to literature

33. Observations • Document is structured to address the fundamental principles • Rigor • Separation of concerns • Modularity • Abstraction • Anticipation of change • Generality • Incrementality • Not every section of the document is relevant to every project, but this should be stated.

34. Requirements’ requirements • Specify only external system behavior • Specify constraints on implementation • Easy to change • Serve as a reference during maintenance • Record forethought about system lifecycle • Characterize responses to undesired events

35. Why spend a lot of time? One of the best-known folk theorems of software engineering is that 60% to 75% of conventional software projects are either never completed or rejected by their intended users. If that range is anywhere near true (and I’ve never met a manager of any experience who disputes it) then more projects than not are being aimed at goals which are either (a) not realistically attainable, or (b) just plain wrong. -- Eric S. Raymond, The Cathedral and The Bazaar

36. Different Circumstances, Different Techniques • Natural language – Structured Natural Language • Data flow diagrams • Office automation • Finite state machines • Telephone systems • Coin-operated machines • Scenarios and Use Case Diagrams • Petri nets • Production plants • Formulas • Matrix inversion package

37. Problems with Natural Language • Lack of clarity • Precision is difficult without making the document difficult to read • Requirements confusion • Functional and non-functional requirements tend to be mixed-up • Requirements amalgamation • Several different requirements may be expressed together

38. Helpful Techniques • Functional approach • List of features • Input and output pairs • Potentially a “shopping list” or “Recipe” • World model approach • List of objects (object oriented) • Place the system in context • “Ingredients and their possible uses” Both lead to a “shopping list” and “dinner”

39. Techniques for Requirements Analysis (review) • Conduct interviews • Build and evaluate prototypes • Observe Customer • Identify important objects/Roles/Functions • Perform Research • Construct glossaries • Use precise notation (be careful with diagrams!) • Question Yourself Focus on the principles – Separation of Concerns – Abstraction, modularity.. etc...

40. Completeness & Consistency • In principle requirements should be both complete and consistent • Complete • They should include descriptions of all facilities required • Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities • In practice, it is impossible to produce a complete and consistent requirements document

41. Conflicts/Consistency • Conflicts between different non-functional requirements are common in complex systems • Spacecraft system • To minimise weight, the number of separate chips in the system should be minimised • To minimise power consumption, lower power chips should be used • However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?

42. Questioning yourself… • Is the requirements specification … • …complete? • … understandable? • …unambiguous • …consistent? (are there any conflicts?) • …verifiable? Testable? • …unbiased? • Can each of the requirements be verified? • Are are all terms and concepts defined?

43. Guidelines for writing requirements • Use the standard format provided for all requirements • Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements • Use text highlighting to identify key parts of the requirement • Avoid the use of computer jargon

44. Some Key points • Requirements set out what the system should do and define constraints on its operation and implementation • Functional requirements set out services the system should provide • Non-functional requirements constrain the system being developed or the development process

45. How Can We Verify Requirements? • Requirements reviews • Systematic manual analysis of the requirements • Prototyping • Using an executable model of the system to check requirements. Covered in Chapter 8 • Test-case generation • Developing tests for requirements to check testability • Automated consistency analysis • Checking the consistency of a structured requirements description

46. Your Tasks • Read and study slides of this lecture • Read Chapters 6, 7, and 9 of Sommerville • Be familiar with system models • Be familiar with formal models