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

Topic 4Summer Today’s Lecture n Requirements Engineering n Components of a Requirements Document

Topic 4Summer Requirements engineering n “The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed” [sommerville] n 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

Topic 4Summer Requirements Engineering Processes n Processes used to discover, analyse and validate system requirements

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

Topic 4Summer The Requirements Engineering Process

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

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

Topic 4Summer Requirements Specification n Specify only external system behavior n Specify constraints on implementation n Easy to change n Serve as a reference during maintenance n Record forethought about system lifecycle n Characterize responses to undesired events

Topic 4Summer Users of a Requirements Document

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

Topic 4Summer Introduction n What is this document about? n Who was it created for? n Who created it? n Outline

Topic 4Summer Executive Summary n Short, succinct, concise, to-the-point, description –Usually no more than one page n Identifies main goals n Identifies key features n Identifies key risks/obstacles

Topic 4Summer Application Context n Describes the situation in which the software will be used –How will the situation change as a result of introducing the software? –“World Model” n 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 n Identifies fundamental assumptions & Likely Changes

Topic 4Summer Functional Requirements n Describe functionality or system services n Identifies all concepts, functions, features, and information that the system provides to its users n 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

Topic 4Summer Examples of Functional Requirements n The user shall be able to search either all of the initial set of databases or select a subset from it. n The system shall provide appropriate viewers for the user to read documents in the document store. n 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.

Topic 4Summer Requirements imprecision n Problems arise when requirements are not precisely stated n Ambiguous requirements may be interpreted in different ways by developers and users n 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

Topic 4Summer Non-functional requirements n Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. n Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless n Environmental, performance, Qualities, and other Requirements

Topic 4Summer Non-Functional Requirement Types

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

Topic 4Summer Examples n 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. n 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.

Topic 4Summer Requirements measures

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

Topic 4Summer Software Qualities n Correctness n Reliability n Robustness n Performance n User friendliness n Verifiability n Maintainability n Repairability n Safety n Evolvability n Reusability n Portability n Understandability n Interoperability n Productivity n Size n Timeliness n Visibility

Topic 4Summer Other Requirements n What about cost? n What about documentation? n What about manuals? n What about tutorials? n What about on-the-job training? n What about requirements that do not fit in any of the previous categories?

Topic 4Summer Time Schedule n By when should all of this be done? –Initial delivery date –Acceptance period –Final delivery date n What are some important milestones to be reached? –Architectural design completed –Module design completed –Implementation completed –Testing completed

Topic 4Summer Potential Risks n 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

Topic 4Summer Future Directions and Expected Changes (aka Lifecycle Considerations) n 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

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

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

Topic 4Summer Glossary n Precise definitions of terms used throughout the requirements document

Topic 4Summer Reference Documents n Pointers to existing processes and tools used within an organization n Pointers to other, existing software that provide similar functionality n Pointers to literature

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

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

Topic 4Summer 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

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

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

Topic 4Summer Helpful Techniques n Functional approach –List of features –Input and output pairs –Potentially a “shopping list” or “Recipe” n 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”

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

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

Topic 4Summer Conflicts/Consistency n Conflicts between different non-functional requirements are common in complex systems n 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?

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

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

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

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

Topic 4Summer Your Tasks 1. Read and study slides of this lecture 2. Read Chapters 6, 7, and 9 of Sommerville –Be familiar with system models –Be familiar with formal models