SEG3201 Basics of the Requirements Process Based on material from: I Bray: An introduction to Requirements Engineering Gerald Kotonya and Ian Sommerville: Requirements Engineering Processes and Techniques, Roger S Pressman: Software Engineering A practitioner's Approach 1
Objectives Definition of requirements and requirements types Introduction to requirements process Requirements activities Importance of a requirements process 2
What are requirements? According to the IEEE A requirement is defined as: (1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or a capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document 8
What are requirements? Requirements capture a system purpose Requirements are expression of the ideas to be embodied in the system or application under development A requirements is a statement about the proposed system that all stakeholders agree must be made true in order for the customer s problem to be adequately solved. Short and concise piece of information Says something about the system All the stakeholders have agreed that it is valid It helps solve the customer s problem 9
Requirements Process All the activities that go into the instigation, scoping and definition of a new or altered software system. Identification of the purpose of a software system and the contexts in which it will be used. Captures real world needs of stakeholders affected by a software system and express them as artifacts that can be implemented by a computing system. Also referred as Requirements Engineering 10
Set of activities Requirements Process not a phase Applies to new as well as evolutive systems Takes context into account how/where system will be used BIG picture important Deals with stakeholders who are they? communication Translates between different worlds Is anything lost in the translation? bridge to design and construction 11
Why is the requirements process important? NIST (National Institute of Standards and Technology's) has published a comprehensive (309 pages) and very interesting report on project statistics and experiences based on data from a large number of software projects http://www.nist.gov/public_affairs/releases/n02 10.htm (May 2002). 70 % of the defects are introduced in the specification phase 30 % are introduced later in the technical solution process. Only 5 % of the specification inadequacies are corrected in the specification phase 95 % are detected later in the project or after delivery where the cost for correction in average is 22 times higher compared to a correction directly in the specification effort. The NIST report concludes that extensive testing is essential, however testing detects the dominating specification errors late in the process. 18
Why is the requirements process important? SEI has an alternative view on improving software development with the CMM/CMMI model for software development. The SEI vision is : The right software, delivered defect free, on time and on cost, every time. "Right software" implies software that satisfies requirements for functionality, performance, and cost throughout its lifetime. "Defect free" software is achieved either through exhaustive testing after coding or by developing the code right the first time. 19
General Problems with the Requirements Process Lack of right expertise (software engineers, domain experts, etc) Initial ideas are often incomplete, wildly optimistic, and firmly entrenched in the minds of the people leading the acquisition process Difficulty of using the complex tools and diverse methods associated with requirements gathering may negate the hoped for benefits of a complete and detailed approach. 20
Types of Requirements Traditional categorization of requirements Functional requirements: functions and features Non functional requirements: constraints on any solution Other terminology Goals: objectives or concerns used to discover and evaluate functional and non functional requirements Domain requirements: requirements derived from application domain User requirements: desired goal or function that a user and other stakeholders expect the system to achieve 21
System requirements vs Software requirements Software is sometimes part of a system A collection of inter related components working together towards some common objective Components may include software, mechanical, electrical and electronic hardware and be operated by people System Engineering Multi disciplinary approach to systems development Software only a part (but often the problematic part) 22
System requirements vs Software requirements According to the IEEE System requirements are the requirements for the system as a whole. In a system containing software components, Software requirements are derived from system requirements. 23
Functional requirements Describe functionality or system services Depend on the type of software, expected users and the type of system where the software is used Functional user requirements may be high level statements of what the system should do but functional system requirements should describe the system services in detail 24
Functional requirements What inputs the system should accept? What outputs the system should produce? What data the system should store that other systems might use? What computations the system should perform? The timing and synchronization of the above? 25
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. 26
Non functional requirements Define system properties and constraints Non functional requirements may be more critical than functional requirements. If these are not met, the system is useless 27
Goals 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 Convey the intention of the system users Verifiable non functional requirement A statement using some measure that can be objectively tested Requirements should be verifiable 28
Examples of Goals A system goal The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. 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. 29
Non Functional Requirements Three main types 1. Categories reflecting: usability, efficiency, reliability, maintainability and reusability Response time Throughput Resource usage Reliability Availability Recovery from failure Allowances for maintainability and enhancement Allowances for reusability 30
Non Functional Requirements 2. Categories constraining the environment and technology of the system. Platform (minimal requirements, OS, devices ) Technology to be used (language, DB, ) 3. Categories constraining the project plan and development methods Development process (methodology) to be used Cost and delivery date Often put in contract or project plan instead 31
Non functional requirements types (Sommerville & Kontoya 1998) Non functional requir ements Product requir ements Ef ficiency requir ements Reliability requir ements Usability requirements Performance requirements Or ganizational requir ements Portability requirements Delivery requirements Space requir ements External requirements Interoperability requirements Implementation requir ements Ethical requirements Standards requirements Legislative requirements Privacy requirements Safety requirements 32
Examples of non functional requirements Product requirement Organisational requirement It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo SP STAN 95 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 33
Requirements measure (Sommerville & Kontoya 1998) Pro perty Speed Size Ease of use Rel iabil it y Robust ness Port abil it y Measure Processed t ransact ions/second U ser/event response t ime Screen refresh t ime K Byt es N umber of RAM chips Training t ime N umber of hel p frames M ean t ime t o fail ure Probabil it y of unavail abil it y Rat e of fail ure occurrence A vail abil it y Time t o rest art aft er fail ure Percent age of event s causing fail ure Probabil it y of dat a corrupt ion on fail ure Percent age of t arget dependent st at ement s N umber of t arget syst ems 34
Domain Requirements Derived from the application domain and describe system characteristics and features that reflect the domain May be new functional requirements, constraints on existing requirements or define specific computations If domain requirements are not satisfied, the system may be unworkable 35
Examples of domain requirements Library system There shall be a standard user interface to all databases which shall be based on the Z39.50 standard. Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer. 36
Requirements Process and related Activities Requirements Process Requirements Inception Elicitation Requirements Development Analysis Requirements Management Specification Verification Based on Larry Boldt, Trends in Requirements Engineering People Process Technology, Technology Builders, Inc., 2001 41
Requirements Process and Related Activities Inception Starts process (business need, market opportunity, great idea,...). Business case and feasibility are built. Requirements elicitation Requirements discovered through consultation with stakeholders Requirements analysis and negotiation Requirements are analyzed and conflicts resolved through negotiation Requirements specification A precise requirements document is produced Requirements validation The requirements document is checked for consistency and completeness Requirements management To cope with requirements changes. Continuous interaction with customers, traceability,... 42
Problem Domain Context for requirements part of the world within which the problem exists need to be understood for effective requirements engineering Domain model set of properties assumed / believed to be true about the environment, relevant to the problem system supposed to behave as required if assumptions are verified problem domain interface solution system A domain model should be re-usable (from Jackson 1995) 49
Requirements Inception Start the process Identification of business need New market opportunity Necessity Great idea Involves Building a business case Preliminary feasibility assessment Preliminary definition of project scope Stakeholders: business managers, marketing people, product managers,... Example of technique: Brainstorming, Joint Application Development (JAD) meeting 50
Requirements Elicitation Gathering of information About problem domain About problems requiring solution About constraints on problem or solution Questions that need to be answered What is the system? What are the goals of system? How is the work done now? What are the problems? How will the system solve these problems? How will the system be used on day to day basis Will performance issues or other constraints affect the way the solution is approached? 51
Requirements Analysis The process of studying and analyzing the customer and the user needs to arrive at a definition of software requirements. Objectives detect and resolve conflicts between requirements discover the bounds of the software and how it must interact with its environment elaborate system requirements to derive software requirements 52
Requirements Specification The invention and definition of a behaviour of a new, solution system such that it will produce the required effects in the problem domain Requirements Analysis defined problem domain and required effects Specification Document A document that clearly and precisely describes, each of the essential requirements (functions, performance, design constraint, and quality attributes) of the software and the external interfaces. Each requirement being defined in such a way that its achievement is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test Different guidelines specification and templates for requirements 53
Requirements Verification and Validation Checks that product is being built right Checks that the right product is being built Helps ensure delivery of what the client wants highly pertinent to RE Need to be performed at every stage during the process Different techniques Simple checks Review Logical analysis Prototypes and enactments Functional test design User manual development 54
Requirements Management Necessary to cope with requirements change Requirements change because: Business process changes Technology changes The problem becomes better understood Traceability is very important R e q u ir e m e n t s docu m en t ra tio n a le 1.1 X X X X... b e c a u s e 1.2 Y Y Y Y D e s ig n docu m en t...d u e t o r e q u i r e m e n t 1.2 Changing requirements is as certain as death and taxes 55
Requirements Products Elicitation notes (Raw) requirements obtained through elicitation. Often un structured, incomplete and inconsistent. Requirements documents User (customer) requirements Detailed requirements (system requirements) Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor Software specification A detailed software description which can serve as a basis for a design or implementation. Written for developers 57
Requirements Products (Sommerville & Kontoya 1998) Requirements definition 1. The software must provide a means of repr esenting and 1. accessing external files created by other tools. Requirements specification 1.1 The user should be provided with facilities to define the type of 1.2 external files. 1.2 Each external file type may have an associated tool which may be 1.2 applied to the file. 1.3 Each external file type may be represented as a specific icon on 1.2 the user s display. 1.4 Facilities should be provided for the icon repr esenting an 1.2 external file type to be defined by the user. 1.5 When a user selects an icon repr esenting an external file, the 1.2 effect of that selection is to apply the tool associated with the type of 1.2 the external file to the file represented by the selected icon. 58
Types of Requirements Documents Two extremes: An informal outline of the requirements using a few paragraphs or simple diagrams requirements definition A long list of specifications that contain thousands of pages of intricate detail requirements specification Requirements xxx x xx xxx x subsystem 1 Requirements documents for large systems are normally arranged in a hierarchy Requirements xxx x xx xxx x sub subsystems Requirements Requirements Requirements Requirements Definition Definition Definition Definition xxx Requirements xxx Requirements xxx Requirements xxx Requirements x Specification Specification x Specification x xx x Specification xx xx xx xxx xxx xxx xxx xxx xxx x xxx xxx x x x x x x xx x xx xx xx xxx xxx xxx x xxx xx x subsystem 2 Requirements Definition Requirements xxx Specification x xx xxx xxx x x xx xxx x sub subsystems Requirements Requirements Requirements Requirements Definition Definition Definition Definition xxx Requirements xxx Requirements Requirements xxx xxx Requirements x Specification Specification Specification x x xx x Specification xx xx xx xxx xxx xxx xxx xxx xxx x xxx xxx x x x x x x xx x xx xx xx xxx xxx xxx x xxx xx x 59 59
The Requirements Analyst Plays an essential communication role talks to users: application domain talks to developers: technical domain translates user requirements into functional requirements and quality goals Needs many capabilities interviewing and listening skills facilitation and interpersonal skills writing and modeling skills organizational ability RE is more than just modeling This is a social activity! 60