Transcript Document
Requirement Engineering Functional and Non-Functional Requirements • • • Functional requirements – Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements – constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements – Requirements that come from the application domain of the system and that reflect characteristics of that domain 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. Process requirements may also be specified mandating a particular CASE system, programming language or development method Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless Non-Functional classifications • • • Product requirements – Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements – Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements – Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. Non-Functional Requirement types 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 Requirements measures Property Speed Size Eas e of use Rel iabi li ty Robust ness P ortabi li ty Meas ure P rocess ed t rans acti ons /s econd User/ Event res ponse ti me Screen refresh t ime K Bytes Number of RAM chips Training time Number of help frames Mean ti me t o failure P robabil ity of unavailabili ty Rat e of failure occurrence Avai labi lit y Time to rest art aft er failure P ercent age of event s caus ing fail ure P robabil ity of data corrupt ion on fail ure P ercent age of target dependent st at ement s Number of t arget syst ems Stake Holders Stake holders – different people who would be interested in the software. Management carries a lot of weight, but are they the actual users? Acceptance of the software depends upon whom? Stakeholders have very general and vague requirements. Some times they trivialize things. Different stake holders have different requirements – sometimes even conflicting. Analysis takes place in an organizational context – internal politics may influence requirements. Stake Holders Management Marketing Specifies High Level Requirements Provides Business Requirements and Project Parameters Software Requirements specifies hardware interfaces the software must respect allocates system requirements to software describe user requirements and quality attributes Systems Engineering Users Hardware Engineering Stake holders - User classes • A study of over 8300 projects revealed that the top two reasons for any project failure are lack of user input and incomplete requirements. • Example of menu driven system for power users – supposed to replace the existing system but failed because of this reason. Requirement Statement versus Requirement Specification Requirement Statement Characteristics • Complete - Each requirement must fully describe the functionality to be delivered. • Correct - Each requirement must accurately describe the functionality to be built. • Feasible - It must be possible to implement each requirement within the • • • • known capabilities and limitations of the system and its environment. Necessary -Each requirement should document something that the customer really need or something that is required for conformance to an external system requirement or standard. Prioritized - Assign an implementation priority to each requirement, feature or use case to indicate how essential it is to a particular product release. Unambiguous - All readers of a requirement statement should arrive at a single, consistent interpretation of it. Verifiable - Examine each requirement to see whether you can devise a small number of tests or use other verification approaches, such as inspection or demonstration, to determine whether the requirement was properly implemented. Requirement Specification Characteristics • Complete - No requirement or necessary information should be missing. • Consistent - Should not conflict with other software or higher-level system or business requirements. • Modifiable - One must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. • Traceable - One should be able to link each requirement to its origin and to the design elements, source code, and test cases that implement and verify the correct implementation of the requirement. Relationship of Several components of Software Requirements Business Requirements Vision and Scope Document User Requirements Quality Attributes Other Non Functional Requirements Use Case Document System Requirements Functional Requirements Functional Specification Document Constraints Mixed level of abstraction • The purpose of the system is to track the stock in a warehouse. • When a loading clerk types in the withdraw command he or she will communicate the order number, the identity of the item to be removed, and the quantity removed. The system will respond with a confirmation that the removal is allowable. Business Requirements • Example of conflicting business requirements – page 97 • Priority setting = Msword An Example In this example an embedded system is to be developed for a booth. This system will be sold to the retail stores and will be used by the store customers. Business Requirements Developers View • Leasing or selling this booth to the retailer. • Selling consumable through this booth to the customer. • Attracting customers to the brand. • Modifying the nature of the historical developer-customer relationship. Business Requirements Retailer’s View • Making money from customer use of this booth. • Attracting more customers to the store. • Saving money of the booth replaces manual operations. Conflicting Objectives The developer might want to establish a high-tech and exciting new direction for the customer, while the retailer wants a simple, turnkey system, and the customer wants convenience and features. Vision Statement • Example – chemical tracking system • Assumptions and dependencies • Scope Vision Statement An Example The Chemical Tracking System will allow scientists to request containers of chemicals to be supplied by the chemical stockroom or by vendors. The location of every chemical container within the company, the quantity of material remaining in it, and the complete history of each container’s location and usage will be known by the system at all times. The company will save 25% on chemical cost by Vision Statement An Example - continued fully exploiting chemicals already available within the company, by disposing of fewer partially used or expired containers, and by using a standard chemical purchasing process. The Chemical Tracking System will also generate all reports required to comply with federal and state government regulations that require the reporting of chemical usage, storage and disposal. Defining the scope Context Diagram • A picture is worth thousand words • Example chemical tracking system Context Diagram Enters the Development Team Sources of Requirements Customer-Developer Relationship • Excellent software products are the result of a well-executed design based on excellent requirements. • High quality requirements result from effective communication and coordination between developers and customers. Building a relationship • Learn about the business – It is not a computer science problem – the problem lies in a different domain than computer science and you must understand it before you can solve it. • Personal experience – SFA tool for Telecom • Speak the user language – Document should be structured and written in a way that the customer finds it easy to read and understand. Use Cases Use Case Model • Use Case • Actor Use Case Model • Use Case – Boundaries of the system are defined by functionality that is handled by the system. – Each use case specifies a complete functionality (from its initiation by an actor until it has performed the requested functionality). • Actor – An entity that has an interest in interacting with the system – a human or some other device or system. Use Case Model A use must always deliver some value to the actor.