Requirements Engineering, Part 2

Requirements Engineering Part 2 Non‐functional Non functional requirements • These define system y p properties p and constraints e.g. g reliability, response time and storage requirements. Constraints are I/O device capability, system representations etc representations, etc. • Process requirements may also be specified mandating a particular IDE, programming language or development method. • Non‐functional requirements may be more critical than functional requirements. If these are not met, the system may be useless. Types of nonfunctional requirement Non‐functional requirements implementation l • Non‐functional requirements q mayy affect the overall architecture of a system rather than the individual components. – For example, example to ensure that performance requirements are met, met you may have to organize the system to minimize communications between components. • A single non non‐functional functional requirement, requirement such as a security requirement, may generate a number of related functional requirements that define system services that are required. i d – It may also generate requirements that restrict existing requirements. Non‐functional Non functional classifications • Product requirements q – 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. 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. Examples of nonfunctional requirements in the h MHC‐PMS Product requirement The MHC‐PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day. day Organizational requirement Users of the MHC‐PMS system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan‐03‐2006‐priv. Goals and requirements • Non‐functional requirements q mayy be veryy difficult to state precisely and imprecise requirements may be difficult to verify. • Goal G l – A general intention of the user such as ease of use. • Verifiable non‐functional requirement q – A statement using some measure that can be objectively tested. • Goals are helpful to developers as they convey the intentions off the h system users. Usability requirements • The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal) • Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. use (Testable non‐functional non functional requirement) Metrics for specifying nonfunctional requirements Property Measure Speed Processed transactions/second User/event response time Screen refresh time Si Size Mbytes Mb t Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems Domain requirements • The system’s system s operational domain imposes requirements on the system. – For example, a train control system has to take into account the braking characteristics in different weather conditions. • D Domain i requirements i t are new functional f ti l requirements, constraints on existing requirements or define specific computations computations. • If domain requirements are not satisfied, the system may be unworkable. Train protection system • This is a domain requirement for a train protection system: • The deceleration of the train shall be computed p as: – Dtrain = Dcontrol + Dgradient – where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train. • It is difficult for a non‐specialist non specialist to understand the implications of this and how it interacts with other requirements. Domain requirements problems • Understandability – Requirements are expressed in the language of the application domain; – This is often not understood by software engineers developing the system. • Implicitness I li it – Domain specialists understand the area so well that they do not think of making the domain requirements explicit. Key points • Requirements q for a software system y set out what the system should do and define constraints on its operation and implementation. • Functional requirements are statements of the services that the system must provide or are descriptions of how some computations must be carried out. • Non‐functional requirements often constrain the system being developed and the development process being used. • They often relate to the emergent properties of the system and therefore apply to the system as a whole. The software requirements document • The software requirements document is the official statement of what is required of the system developers. • Should include both a definition of user requirements and a specification of the system requirements. • It is NOT a design document. As far as possible, it should h ld set off WHAT the h system should h ld d do rather h than h HOW it should do it. Agile methods and requirements • Many a y ag agilee methods e ods aargue gue that a p producing oduc g a requirements document is a waste of time as requirements change so quickly. • The document is therefore always out of date. • Methods such as XP use incremental requirements engineering i i and d express requirements i t as ‘user ‘ stories’ t i ’ (discussed in Chapter 3). • This is practical for business systems but problematic for systems that require a lot of pre‐delivery analysis (e.g. critical systems) or systems developed by several teams. Users of a requirements document Requirements document variability • Information in requirements document depends on type of system and the approach to development used. • Systems developed incrementally will, typically, have less detail in the requirements document. • Requirements documents standards have been designed e.g. IEEE standard. These are mostly applicable l bl to the h requirements ffor llarge systems engineering projects. The structure of a requirements document Chapter Description Preface This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. Introduction This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. Glossary This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader. User requirements Here, you describe the services provided for the user. The nonfunctional definition system requirements should also be described in this section. This d description i ti may use natural t l language, l di diagrams, or other th notations t ti th t are that understandable to customers. Product and process standards that must be followed should be specified. System architecture This chapter should present a high-level overview of the anticipated system architecture showing the distribution of functions across system modules. architecture, modules Architectural components that are reused should be highlighted. The structure of a requirements document Chapter Description System requirements specification This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. System y models This might g include g graphical system y models showing g the relationships between the system components and the system and its environment. Examples of possible models are object models, data-flow models, or semantic data models. System evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system. Appendices These should provide detailed, specific information that is related to the application being developed; for example, example hardware and database descriptions. descriptions Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used by the system and the relationships between data. Index Several indexes to the document may be included. included As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on.