Requirements Engineering, Part 1 | California State University, Northridge

University:
California State University, Northridge
Course:
COMP 380/L | Introduction to Software Engineering and Lab
Academic year:

2011
Views:

321

Pages:

12
Author:

Jared Bowers

Requirements Engineering Part 1 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. • The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. What is a requirement? • It mayy range g from a high‐level g abstract statement of a service or of a system constraint to a detailed mathematical functional specification. • This h is inevitable bl as requirements may serve a dual d l function – May be the basis for a bid for a contract ‐ therefore must be open to interpretation; – May be the basis for the contract itself ‐ therefore must be defined in detail; – Both these statements may be called requirements. Requirements abstraction (Davis) “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client li t in i more d detail t il so that th t th the client li t understands d t d and d can validate lid t what h t the software will do. Both of these documents may be called the requirements document for the system.” Types of requirement • User requirements – Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. • System requirements – A structured d document d setting i out detailed d il d d descriptions i i off the system’s functions, services and operational constraints. Defines what should be implemented p so mayy be part of a contract between client and contractor. User and system requirements Readers of different types of requirements specification f Functional and non‐functional requirements i • 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. situations – May state what the system should not do. • Non‐functional requirements – C Constraints t i t on the th services i or functions f ti offered ff d by b the th system t such h as timing constraints, constraints on the development process, standards, etc. – Often apply to the system as a whole rather than individual features or services. • Domain requirements – Constraints on the system from the domain of operation Functional requirements • Describe functionality or system services. • Depend on the type of software, expected users and the type yp of system y where the software is used. • Functional user requirements may be high‐level statements of what the system y should do. • Functional system requirements should describe the system services in detail. Functional requirements for the MHC‐ PMS • A user shall be able to search the appointments lists for all clinics. • The system y shall ggenerate each day, y, for each clinic,, a list of patients who are expected to attend appointments that day. • Each staff member using the system shall be uniquely identified by his or her 8‐digit employee number. Requirements imprecision • Problems arise when requirements are not precisely stated. • Ambiguous g requirements q mayy be interpreted p in different ways by developers and users. q 1 • Consider the term ‘search’ in requirement – User intention – search for a patient name across all appointments in all clinics; – Developer interpretation – search for a patient name in an individual clinic. User chooses clinic then search. Requirements completeness and consistency • In p principle, p , requirements q should be both complete p 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 p practice,, it is almost impossible p to p produce a complete p and consistent requirements document.