What Is a Requirement?

Home , Functional specification, Requirement, Requirements engineering, Software requirements

• May range from – a high-level abstract statement of a service or – a statement of a system constraint to a Software Requirements detailed mathematical functional specification • Requirements may be used for – a bid for a contract Descriptions and specifications • must be open to interpretation of a system – the basis for the contract itself • must be defined in detail • Both the above statements may be called requirements

Example Example

…… 4.A.5 The database shall support the generation and control of conﬁguration objects; that is, objects which are themselves groupings of other objects in the database. The conﬁguration control facilities shall allow access to the objects in a version group by the use of an incomplete name. ……

1 Types of requirements User requirements readers

• Written for customers • Client managers – User requirements • Statements in natural language plus diagrams of the • System end-users services the system provides and its operational constraints. • Client engineers • Written as a contract between client and • Contractor managers contractor – System requirements • System architects • A structured document setting out detailed descriptions of the system services. • Written for developers – Software specification • A detailed software description which can serve as a basis for a design or implementation.

System requirements readers Software specification readers

• System end-users • Client engineers (maybe) • Client engineers • System architects • System architects • Software developers • Software developers

2 Functional requirements

• Statements of services the system should provide, how the system We will come back to user should react to particular inputs and system requirements and how the system should behave in particular situations.

Examples of functional Functional requirements requirements • Describe functionality or system services 1. The user shall be able to search either • Depend on the type of software, all of the initial set of databases or expected users and the type of system select a subset from it. where the software is used 2. The system shall provide appropriate • Functional user requirements may be viewers for the user to read documents high-level statements of what the in the document store. system should do but functional system 3. Every order shall be allocated a unique requirements should describe the system identifier (ORDER_ID) which the user services in detail shall be able to copy to the account’s permanent storage area.

3 Requirements completeness and Requirements imprecision consistency • Problems arise when requirements are • In principle, requirements should be both not precisely stated complete and consistent • Ambiguous requirements may be • Complete interpreted in different ways by – They should include descriptions of all facilities required developers and users • Consistent • Consider the term ‘appropriate viewers’ – There should be no conflicts or – User intention - special purpose viewer for contradictions in the descriptions of the each different document type system facilities – Developer interpretation - Provide a text • In practice, it is difficult (?impossible?) viewer that shows the contents of the to produce a complete and consistent document requirements document

What requirements are these? Non-functional requirements

• It shall be possible for all necessary • constraints on the services or communication between the APSE and the functions offered by the system user to be expressed in the standard Ada character set such as timing constraints, • The system development process and constraints on the development deliverable documents shall conform to process, standards, etc. the process and deliverables defined in XYZCo-SP-STAN-95 • The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system

4 Non-functional requirements Non-functional classifications • Define system properties and constraints • Product requirements e.g. reliability, response time and – Requirements which specify that the storage requirements. Constraints are I/ delivered product must behave in a particular O device capability, system way e.g. execution speed, reliability, etc. representations, etc. • Organizational requirements • Process requirements may also be – Requirements which are a consequence of specified mandating a particular system, organizational policies and procedures e.g. process standards used, implementation programming language or development requirements, etc. method • External requirements • Non-functional requirements may be – Requirements which arise from factors which more critical than functional are external to the system and its requirements. If these are not met, the development process e.g. interoperability system is useless requirements, legislative requirements, etc.

Non-functional requirement Non-functional requirements types examples • Product requirement – 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set • Organizational requirement – 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP- STAN-95 • External requirement – 7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system

5 Goals and requirements Examples

• Non-functional requirements may be very • A system goal difficult to state precisely and imprecise – The system should be easy to use by requirements may be difficult to verify. experienced controllers and should be organized in such a way that user errors are • Goal minimized. – A general intention of the user such as ease of use • A verifiable non-functional requirement – Experienced controllers shall be able to use • Verifiable non-functional requirement all the system functions after a total of two – A statement using some measure that can be hours training. After this training, the objectively tested average number of errors made by • Goals are helpful to developers as they experienced users shall not exceed two per convey the intentions of the system day. users

Requirements measures Requirements interaction

Property Measure • Conflicts between different non- Speed •Processed transactions/second functional requirements are common in •User/event response time •Screen refresh time complex systems Size •K Bytes • Spacecraft system •Number of RAM chips

Ease of use •Training time – To minimize weight, the number of separate •Number of help frames chips in the system should be minimized Reliability •Mean time to failure – To minimize power consumption, lower power •Probability of unavailability chips should be used •Rate of failure occurrence •Availability – However, using low power chips may mean Robustness •Time to restart after failure that more chips have to be used. Which is •Percentage of events causing failure the most critical requirement? •Probability of data corruption on failure Portability •Percentage of target dependent statements •Number of target systems

6 Domain requirements Domain requirements

• Requirements that come from the • Derived from the application domain and application domain of the system describe system characteristics and and that reflect characteristics of features that reflect the domain that 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

Library system domain Domain requirements problems requirements • There shall be a standard user interface • Understandability to all databases which shall be based on – Requirements are expressed in the the Z39.50 standard. language of the application domain • Because of copyright restrictions, some – This is often not understood by documents must be deleted immediately software engineers developing the on arrival. Depending on the user’s system requirements, these documents will • Implicitness either be printed locally on the system – Domain specialists understand the area server for manually forwarding to the so well that they do not think of user or routed to a network printer. making the domain requirements explicit

7 User requirements

• Should describe functional and non- functional requirements so that Back to user and system they are understandable by system requirements users who don’t have detailed technical knowledge • User requirements are defined using natural language, tables and diagrams

Database requirement Requirement problems • Database requirements includes both conceptual and detailed …… information 4.A.5 The database shall support the generation and control of – Describes the concept of configuration conﬁguration objects; that is, objects which are themselves groupings control facilities of other objects in the database. The conﬁguration control facilities shall allow access to the objects in a version group by the use of an – Includes the detail that objects may incomplete name. be accessed using an incomplete name ……

8 Editor grid requirement Requirement problems • Grid requirement mixes three …… different kinds of requirement 2.6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an – Conceptual functional requirement (the option on the control panel. Initially, the grid is off. The grid may be need for a grid) turned on and off at any time during an editing session and can be – Non-functional requirement (grid units) toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-ﬁt view but the number of grid – Non-functional UI requirement (grid lines shown will be reduced to avoid ﬁlling the smaller diagram switching) with grid lines. ……

Problems with natural language

• Lack of clarity – Precision is difficult without making the document difficult to read Why the problems? • Requirements confusion – Functional and non-functional requirements tend to be mixed-up • Requirements mix-up – Several different requirements may be expressed together

9 Structured presentation Detailed user requirement

Guidelines for writing System requirements requirements • Invent a standard format and use it • More detailed specifications of user for all requirements requirements • Use language in a consistent way. • Serve as a basis for designing the Use “shall” for mandatory system requirements, “should” for desirable • May be used as part of the system requirements contract • Use text highlighting to identify key parts of the requirement • Avoid the use of computer jargon

10 Problems with NL specification Alternatives to NL specification

• Ambiguity – The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult • Over-flexibility – The same thing may be said in a number of different ways in the specification • Lack of modularisation – NL structures are inadequate to structure system requirements

Structured language Form-based specifications specifications • A limited form of natural language • Definition of the function or entity may be used to express • Description of inputs and where requirements they come from • This removes some of the problems • Description of outputs and where resulting from ambiguity and they go to flexibility and imposes a degree of • Indication of other entities required uniformity on a specification • Pre and post conditions (if • Often best supported using a appropriate) forms-based approach • The side effects (if any)

11 PDL-based requirements Form-based node specification definition • Requirements may be defined using a language like a programming language but with more flexibility of expression • Most appropriate in two situations • Where an operation is specified as a sequence of actions and the order is important • When hardware and software interfaces have to be specified • Disadvantages are – The program definition language (PDL) may not be sufficiently expressive to define domain concepts – The specification will be taken as a design rather than a specification

Part of an ATM specification PDL disadvantages

• PDL may not be sufficiently expressive to express the system functionality in an understandable way • Notation is only understandable to people with programming language knowledge • The requirement may be taken as a design specification rather than a model to help understand the system

12 Interface specification PDL interface description

• Most systems must operate with other systems and the operating interfaces must be specified as part of the requirements • Three types of interface may have to be defined – Procedural interfaces – Data structures that are exchanged – Data representations • Formal notations are an effective technique for interface specification

Viewpoint-oriented elicitation Banking ATM system

• Stakeholders represent different • The example used here is an auto-teller ways of looking at a problem or system which provides some automated banking services problem viewpoints • I use a very simplified system which • This multi-perspective analysis is offers some services to customers of the important as there is no single bank who own the system and a narrower range of services to other customers correct way to analyze system • Services include cash withdrawal, requirements message passing (send a message to request a service), ordering a statement and transferring funds

13 Autoteller viewpoints Types of viewpoints

• Bank customers – Data sources or sinks • Viewpoints are responsible for producing or consuming • Representatives of other banks data. • Hardware and software maintenance • Analysis involves checking that data is produced and consumed and that assumptions about the source and engineers sink of data are valid • Marketing department – Representation frameworks • Bank managers and counter staff • Viewpoints represent particular types of system model. • Database administrators and security • These may be compared to discover requirements staff that would be missed using a single representation. Particularly suitable for real-time systems

• Communications engineers – Receivers of services • Personnel department • Viewpoints are external to the system and receive services from it. • Most suited to interactive systems

External viewpoints Method-based analysis

• Natural to think of end-users as • Widely used approach to requirements receivers of system services analysis. Depends on the application of a structured method to understand the • Viewpoints are a natural way to system structure requirements elicitation • Methods have different emphases. Some • It is relatively easy to decide if a are designed for requirements elicitation, viewpoint is valid others are close to design methods • Viewpoints and services may be • A viewpoint-oriented method (VORD) is used to structure non-functional used as an example here. It also illustrates the use of viewpoints requirements

14 The VORD method VORD process model • Viewpoint identification Viewpoint Identification – Discover viewpoints which receive system services and identify the services provided to each viewpoint Viewpoint Structuring • Viewpoint structuring – Group related viewpoints into a hierarchy. Common services are provided at higher- Viewpoint levels in the hierarchy Documentation • Viewpoint documentation – Refine the description of the identified Viewpoint System viewpoints and services Mapping • Viewpoint-system mapping – Transform the analysis to an object-oriented design

VORD standard forms Viewpoint identification

Query Get Customer Cash Transaction balance transactions database withdrawal log Card Remote Manager Order Machine returning software cheques supplies upgrade Account Message Software log information size Bank Invalid User teller user interface System cost Foreign customer Printe r Security Account Stolen Order Hardware card statement Card holder maintenance retention Message passing Remote Update Funds Card Reliability diagnostics account transfer validation

15 Viewpoint service information Viewpoint data/control

Account Holder Foreign Customer Bank Teller Service List Service List Service List Account Control Input Data Input 1. Withdraw cash 1. Withdraw cash 1. Run diagnostics Holder 2. Query balance 2. Query balance 2. Add cash 1. Start transaction 1. Card details 3. Order checks 3. Add paper 2. Cancel transaction 2. PIN 4. Send message 4. Send Message 3. End transaction 3. Amount required 5. Transaction list 4. Select service 4. Message 6. Order statement 7. Transfer funds

Customer/cash withdrawal Viewpoint hierarchy templates • Reference • Reference – Cash withdrawal Services – Customer • Rationale Withdraw cash – To improve customer service • Attributes and reduce paperwork Query balance – Account number • Specification – PIN – Users choose this service by – Start transaction pressing the cash withdrawal Services button. They then enter the • Events amount required. This is Order checks – Select service confirmed and, if the funds Send message – Cancel transaction are low, the balance is delivered Transaction list – End transaction Order statement • VPs • Services – Customer Transfer funds – Cash withdrawal • Non-functional requirements – Balance enquiry – Deliver cash within 1 minute • Sub-VPs of amount being confirmed – Account holder • Provider

– Foreign customer – Filled in later

16 Scenarios Scenario descriptions • Scenarios are descriptions of how a • System state at the beginning of system is used in practice the scenario • They are helpful in requirements • Normal flow of events in the elicitation as people can relate to scenario these more readily than abstract • What can go wrong and how this is statement of what they require handled from a system • Other concurrent activities

• Scenarios are particularly useful for • System state on completion of the adding detail to an outline scenario requirements description

Event scenario - start Event scenarios transactionEllipses. data provided from or Card present • Event scenarios may be used to Card delivered to a viewpoint describe how a system responds to Request PIN Valid card the occurrence of some particular PIN User OK event such as ‘start transaction’ Account Account Select Number Validate user number service • VORD includes a diagrammatic PIN convention for event scenarios. Timeout Control information enters and Return card – Data provided and delivered leaves Incorrectat the PINtop of each box Re-enter PIN – Control information Invalid card Name of next event is in – Exception processing Return card Datashaded leaves boxfrom the – The next expected event right ofIncorrect each boxPIN Stolen card ExceptionsReturn card are shown at the Retain card bottom of each box

17 Use cases Lending use-case

• Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself

• A set of use cases should describe Lending Services all possible interactions with the system Actors Class of Interactions

Library use-cases Sequence Diagrams

• Sequence diagrams may be used to Lending Services add detail to use-cases by showing Library user the sequence of event processing in the system

User administration Library staff

Supplier

Catalog Services

18 Catalogue management: Requirements engineering Sequence Diagram processes Item: Books: Library • The processes used for RE vary widely catalog item depending on the application domain, the Bookshop Cataloguer: people involved and the organization supplier Library staff developing the requirements Acquire New • However, there are a number of generic activities common to all processes Catalog item – Requirements elicitation – Requirements analysis Dispose – Requirements validation – Requirements management Uncatalog item

The Requirements Engineering Feasibility studies Process Feasibility • A feasibility study decides whether Study or not the proposed system is Requirements worthwhile Elicitation & Analysis Requirements • A short focused study that checks Feasibility Specification – If the system contributes to Report Requirements organizational objectives System Validation – If the system can be engineered using Models current technology and within budget User & System Requirements – If the system can be integrated with other systems that are used Requirements Document

19 Feasibility study implementation Elicit: by Webster dictionary

• Based on information assessment (what is Main Entry: elic·it required), information collection and Pronunciation: i-'li-s&t report writing Function: transitive verb Etymology: Latin elicitus, past participle of • Questions for people in the organization elicere, from e- + lacere to allure – What if the system wasn’t implemented? Date: 1605 – What are current process problems? 1 : to draw forth or bring out (something – How will the proposed system help? latent or potential)

Elicitation Requirements Analysis

• Sometimes called requirements elicitation • Stakeholders don’t know what they really or requirements discovery want • Involves technical staff working with • Stakeholders express requirements in customers to find out about the their own terms application domain, the services that the • Different stakeholders may have system should provide and the system’s conflicting requirements operational constraints • Organizational and political factors may • May involve end-users, managers, influence the system requirements engineers involved in maintenance, domain • The requirements change during the experts, trade unions, etc. These are analysis process. New stakeholders may called stakeholders emerge and the business environment change

20 The requirements analysis process Requirements validation Requirements • Concerned with demonstrating that Definition & the requirements define the system Requirements Specification Validation that the customer really wants • Requirements error costs are high

Process Domain so validation is very important Prioritization Entry Understanding – Fixing a requirements error after delivery may cost up to 100 times the Requirements Conflict cost of fixing an implementation error Collection Resolution

Classification

Requirements validation Requirements Validation techniques • Validity. Does the system provide the • Requirements reviews functions that best support the – Systematic manual analysis of the customer’s needs? requirements • Consistency. Are there any requirements • Prototyping conflicts? – Using an executable model of the system to • Completeness. Are all functions required check requirements. by the customer included? • Test-case generation • Realism. Can the requirements be – Developing tests for requirements to check implemented given available budget and testability technology • Automated consistency analysis – Checking the consistency of a structured • Verifiability. Can the requirements be requirements description checked?

21 Requirements reviews Review checks • Regular reviews should be held while the • Verifiability. Is the requirement requirements definition is being realistically testable? formulated • Comprehensibility. Is the • Both client and contractor staff should be involved in reviews requirement properly understood? • Reviews may be formal (with completed • Traceability. Is the origin of the documents) or informal. Good requirement clearly stated? communications between developers, • Adaptability. Can the requirement customers and users can resolve problems be changed without a large impact at an early stage on other requirements?

Requirements management Requirements management planning

• Requirements management is the process • During the requirements engineering of managing changing requirements during process, you have to plan: the requirements engineering process and – Requirements identification system development • How requirements are individually identified • Requirements are inevitably incomplete – A change management process • The process followed when analyzing a requirements and inconsistent change – New requirements emerge during the process – Traceability policies as business needs change and a better • The amount of information about requirements understanding of the system is developed relationships that is maintained – Different viewpoints have different – CASE tool support requirements and these are often • The tool support required to help manage contradictory requirements change

22 Traceability A traceability matrix

• Traceability is concerned with the relationships between requirements, their sources and the system design • Source traceability – Links from requirements to stakeholders who proposed these requirements • Requirements traceability – Links between dependent requirements • Design traceability – Links from the requirements to the design U = “uses the requirement”, R = “Some other weaker relationship”

CASE tool support

• Requirements storage – Requirements should be managed in a secure, managed data store • Change management – The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated • Traceability management – Automated retrieval of the links between requirements

23 Enduring and volatile Requirements change requirements • Enduring requirements. Stable • The priority of requirements from requirements derived from the core different viewpoints changes during activity of the customer organisation. the development process E.g. a hospital will always have doctors, nurses, etc. May be derived from domain • System customers may specify models requirements from a business • Volatile requirements. Requirements perspective that conflict with end- which change during development or when user requirements the system is in use. In a hospital, • The business and technical requirements derived from health-care policy environment of the system changes during its development

24 Requirements evolution Requirements change management • Should apply to all proposed changes to Initial Changed understanding understanding the requirements of problem of problem • Principal stages – Problem analysis. Discuss requirements problem and propose change – Change analysis and costing. Assess effects Initial Changed of change on other requirements requirements requirements – Change implementation. Modify requirements document and other documents to reflect change Time

Requirements change management The requirements document

Identified problem • The requirements document is the official statement of what is Problem analysis and change specification required of the system developers • Should include both a definition and

Change analysis a specification of requirements and costing • It is NOT a design document. As far as possible, it should set of Change implementation WHAT the system should do rather than HOW it should do it Revised requirements

25 Users of a requirements Requirements document document requirements – System customers • Specify external system behaviour • Specify the requirements and read them to check that they meet their needs • Specify implementation constraints – Managers • Easy to change • Use the requirements document to plan a bid for the system and to plan the system • Serve as reference tool for maintenance – System engineers • Record forethought about the life cycle • Use the requirements to understand what system is to be developed of the system i.e. predict changes – System test engineers • Characterise responses to unexpected • Use the requirements to develop validation tests for the system events – System maintenance engineers • Use the requirements to help understand the system and the relationship between its parts

IEEE requirements standard

• Introduction • General description • Specific requirements • Appendices • Index • This is a generic structure that must be instantiated for specific systems