1

Capturing The Requirements

CEN 4020Software Engineering

By Darren Quichocho

Requirements What is a requirement?

◦ An expression of desired behavior◦ Deals with objects or entities, the states they can be in, and the

functions that are performed to change those states and characteristics

◦ It is important to note that the requirements focus on the customer and the problem, not on the solution or implementation

2

Forms of Requirements Requirements can loosely be prioritized into three categories

◦ Essential – requirements that must be absolutely met◦ Desirable – requirements that are highly desirable but not necessary◦ Optional – Requirements that are possible but could be eliminated

We’ll use a credit card billing system as an example◦ Essential – list current charges, sum them, and request payment◦ Desirable – the ability to separate the charges by purchase-type ◦ Optional – Printing the credits and debits in different colors

3

Steps of Capturing Requirements The requirements are usually decided by a Requirements Analyst or a Systems Analyst

The end result is a Software Requirements Specification (SRS)◦ Used to communicate to other software developers how the final product should behave.

4

How Users and Developers View Each Other

5

Identifying the requirements that the user or customer wants is not always easy. Often, the customer does not actually know what they want or simply cannot accurately describe their needs. In the same way, developers may not always understand business concerns or jargon. As a result, the process of eliciting requirements can be lengthy.

Types of Requirements Functional – describes required behavior in terms of required activities such as reactions to inputs or the state of each entity before and after an activity occurs

Quality or Nonfunctional – describes some quality characteristic that the software solution must process such as fast response time, ease of use, high reliability, or low maintenance cost

Design Constraint – a design decision, such as choice of platform or interface components, that has already been made and that restricts the set of solutions to the problem

Process Constraint – a restriction on the techniques or resources that can be used to build systems

6

Requirements Documents

Requirements Definition – a complete listing of everything the customer wants to achieve◦ Aimed at a business audience, such as clients, customers, and users◦ Typically written jointly by the client and the requirements analyst◦ Written entirely in terms of the environment, describing how the

environment will be affected by the proposed system

Requirements Specification – restates the requirements as a specification of how the proposed system shall behave ◦ Aimed at a technical audience, such as designers, testers, and project

managers◦ Also written in terms of the environment, except that it refers solely

to the entities that are accessible to the system◦ Written by the requirements analyst and used by developers

7

Requirements Documents

Below is a depiction of the separation between the requirements definition and the requirements specification

8

Importance of Requirements Analysis

If the requirement analysis phase is not completed properly or in a sluggish manner then there might be inconsistencies in the final product.

Top Factors of Failed Projects:1. Incomplete Requirements (13.1%)

2. Lack of User Involvement (12.4%)

3. Lack of Resources (10.6 %)

4. Unrealistic Expectations (9.9%)

5. Lack of Executive Support (9.3%)

6. Changing Requirements and Specifications (8.7%(

7. Lack of Planning (8.1%)

8. System No Longer Needed (7.5%)

9

Characteristics of Requirements

1. Are the Requirements Correct?◦ Both the developer and the customer should agree on the set of

requirements

2. Are the Requirements Consistent?◦ Requirements are inconsistent if they are impossible to satisfy

simultaneously

3. Are the Requirements Unambiguous?◦ Requirements are ambiguous if multiple people can read them and

walk away with different but valid interpretations

4. Are the Requirements Complete?◦ They are complete if it specifies required behavior and output for all

possible inputs in all possible states under all possible constraints

10

Characteristics of Requirements

4. Are the Requirements Consistent (cont.)?◦ Externally Complete – all states, state changes, inputs, products, and

constraints are described by some requirements◦ Internally Complete – no undefined terms among the requirements

5. Are the Requirements Feasible?◦ Feasibility comes into play when a customer requires two or more quality

requirements. For example, they want an inexpensive system that analyzes huge amounts of data and outputs an analysis in seconds.

6. Are the Requirements Relevant?◦ Need to stay focused on essential and desirable requirements. Requirements

that are not relevant can end up limiting the developer

11

Characteristics of Requirements

7. Are the Requirements Testable?◦ Testable if they suggest acceptance tests that would clearly demonstrate

whether the eventual product meets the requirements

8. Are the Requirements Traceable?◦ The requirements should be organized and uniquely labeled for easy

reference

12

Modeling Notation Entity Relationship Diagram (ER Diagram) – graphical notational paradigm used to model the relationships among objects in a problem description or to model the structure of a software application

13

Entity (rectangle) – objects with common properties or behaviorsRelationship (diamond) – specifies type of relationship between entitiesAttribute (annotation) – describes data or property of an entity

Modeling Notation Unified Modeling Language (UML) – collection of notations used to document software specifications and designs◦ Typically uses a class diagram – a sophisticated ER diagram relating

the classes in the specification. Each class has a name, a set of attributes, a set of operations

◦ Class-scope attribute – (underlined attribute) a data value that is hared by all instances of the class

◦ Class-scope operation – (underlined operation) operation performed by the abstract class on a new instance

◦ Association◦ Aggregate – “has a” association represented by a white diamond◦ Generalization – “is a” association represented by a triangle on one end

◦ Association Class – relates attributes and operations to an association

14

Modeling Notation An example UML chart

15

Modeling Notation Event Trace – a graphical description of a sequence of events that are exchanged between real-world entities. Traces are preferred because of they are relatively precise but also easy to understand

The trace on the left represents typical behavior and the trace on the right represents the expected behavior

16

Modeling Notation Message Sequence Charts – an enhanced event-trace notation with facilities for creating and destroying entities, specifying actions and timers, and composing traces◦ Vertical line represents a participating entity◦ A message is depicted as an arrow from the sending entity to the

receiving entity◦ Actions are specified as labelled rectangles positioned on an entity's

execution line◦ Conditions are important states in an entity's evolution, represented

as labelled hexagon

17

Modeling Notation Message Sequence chart for a library loan transaction

18

Modeling Notation State Machines – a graphical description of all dialog between the system and its environment. Useful in representing dynamic behavior

19

State – each node represents a stable set of conditions that exists between event occurrencesTransition – represents a change in behavior or condition due to the occurrence of an eventDeterministic – a state machine is deterministic if for each state and event there is a unique response

Modeling Notation UML State Chart Diagram – depicts the dynamic behavior of the objects in a UML class. Gives a static big picture view of a problem

20

Uses state hierarchy to simplify diagrams by using superstates which combine states with common transitionsA superstate can be thought of as a submachineSubmachines operate concurrently, meaning that an instance could at any time receive and respond to events of interest to either submachine

Modeling Notation Petri Nets – a form of state transition notation that is used to model concurrent activities and their interactions ◦ Circles (places) represent activities or conditions◦ Bars represents transitions◦ Arcs connect a transition with its input places and its output places◦ The places are populated with tokens, which act as enabling

conditions for the transitions◦ Each arc can be assigned a weight that specifies how many tokens

are removed from arc's input place, when the transition fires

21

Modeling Notation

22

Petri Net for the behavior of a book loan

Modeling Notation Data Flow Diagram (DFD) – models functionality and the flow of data from one function to another◦ A bubble represents a process◦ An arrow represents data flow◦ A data store: a formal repository or database of information◦ Rectangles represent actors: entities that provide input data or

receive the output result

23

Modeling Notation DFD for a library loan system

24

Modeling Notation Use-Case Diagram – depicts observable, user initiated functionality in terms of interactions between the system and its environment

25

Modeling Notation Formal Methods or Approaches – mathematically based specification and design techniques. ◦ Model requirements or software behaviour as a collection of

mathematical functions or relations that map systems inputs to system outputs

◦ Encouraged by many software engineers who build safety critical systems◦ For example, Defence Standard 00-56, a British standard for

building safety critical systems, requires that formal specification and design be used to demonstrate required functionality, reliability and safety

26

Modeling Notation Decision Tables – a tabular representation of a functional specification that maps events and conditions to appropriate responses or actions

27

Specification is informal because the inputs and outputs may be expressed in natural language, as mathematical expressions, or both.Useful in examining consistency and correlations

Modeling Notation Parnas Tables – tabular representations of mathematical functions or relations. A collection of table types and abbreviation strategies for organizing and simplifying functional and relational expressions◦ The column and row headers are used to specify cases◦ The internal table entries store the possible function results◦ An entry “X” either could be invalid under the specified conditions or

the combination of conditions is infeasible

28

Modeling Notation First Order Logic – commonly used to express properties of software requirements. Comprising typed variables, constants, functions, predicates, like relational operators, equality, logical connectives, and quantifiers.

Temporal Logic – introduces additional logical connectives for constraining how variables can change value over time

Object Constraint Language (OCL) – an attempt to create a constraint language that is both mathematically precise and easy for nonmathematicians, like customers, to read, write, and understand

29

Modeling Notation A partial library class model with three classes annotated with OCL constraints

30

Modeling Notation Z – (pronounced “zed”) a formal requirements-specification language that structures set-theoretic definitions of variables into a complete abstract-data-type model of a problem , and uses logic to decompose a specification into manageably sized modules, called Schemas.◦ Schemas specify:

◦ The system state in terms of typed variables, and invariants on variables values

◦ The systems initial state◦ Operations

◦ Z offers the precision of a mathematical notation, such as being able to evaluate specifications using proofs or automated checks

31

Model Notation Library example specified in Z

32

Prototyping Requirements

Throwaway Prototype – software that is developed to learn more about a problem or about a proposed solution and is never intended to be part of the delivered software

Evolutionary Prototype – software that is developed not only to help us answer questions but also to be incorporated in the final product

Rapid Prototyping – both throwaway and evolutionary prototype are sometimes referred to as rapid prototyping because they involve building software in order to answer questions about the requirements

33

Prototyping Requirements

34

A simple representation of a key-board entry prototype

A slightly more developed calendar-based prototype

A more sophisticated prototype that will most likely provide the fastest selection

Documenting Requirements

It is important to keep a set of documents that defines the requirements. These documents need to be clear and contain precise diagrams so that both the customer and the developer may refer back to them throughout the development process. Consistency is key in documenting requirements.

As we discovered before there are two main documents:◦ Requirements Definition◦ Requirements Specification

35

Documenting Requirements

Requirements Definition

1. Outline general purpose and scope of the system

2. Describe background and rationale for proposal

3. Describe essential characteristics and core functionality of solution

4. Describe the environment in which the system will operate, taking into account the background and capability of the intended user

5. Evaluate customers proposal for the problem checking for design constraints

6. Describe any assumed environmental conditions that could cause the system to fail

36

Documenting Requirements

Requirement Specification

1. Document system interface, describing all inputs and outputs in detail, including sources, destinations, data formats, and timing constraints.

2. Restate the required functionality in terms of the interfaces inputs and outputs. This can include data-flow diagrams, state machines, event traces, and entity-relationship diagrams.

3. Devise fit criteria for the quality requirements to demonstrate whether the system meets the needs of the customer.

37

IEEE Standards for Requirements Specification

38

1. Introduction to the Document1.1 Purpose of the Product1.2 Scope of the Product1.3 Acronyms, Abbreviations, Definitions1.4 References1.5 Outline of the rest of the SRS

2. General Description of Product2.1 Context of Product2.2 Product Functions2.3 User Characteristics2.4 Constraints2.5 Assumptions and Dependencies

3. Specific Requirements3.1 External Interface Requirements

3.1.1 User Interfaces3.1.2 Hardware Interfaces3.1.3 Software Interfaces3.1.4 Communications Interfaces

3.2 Functional Requirements3.2.1 Class 13.2.2 Class 2…

3.3 Performance Requirements3.4 Design Constraints3.5 Quality Requirements3.6 Other Requirements

4. Appendices

1. Introduction◦ Purpose◦ Scope◦ Definitions, acronyms, and abbreviations◦ References◦ Overview

2. Overall description◦ Product perspective◦ Product functions◦ User characteristics◦ Constraints◦ Assumptions and dependencies

3. Specific requirements

An IEEE SRS should follow the general format below. To the right is a more detailed example using classes and objects.

Participants and Their Roles

Clients: pay for the software to be developed

Customers: buy the software after it is developed

Users: use the system

Domain experts: familiar with the problem that the software must automate

Market Researchers: conduct surveys to determine future trends and potential customers

Lawyers or auditors: familiar with government, safety, or legal requirements

Software engineers or other technology experts: design the system

39

Validation and Verification

It is essential for the requirements to meet the customers needs. As a result we must verify and validate them before starting development.

Requirements Validation – checks that our requirements definition accurately reflects the customers needs.

Requirements Verification – we check that one document conforms to another, that is, we check that the code conforms to the design, and that the design conforms to the requirements specification.

In short, validation checks that we build the system right, and verification checks that we build the right system.

40

Validation and Verification

41

Validation Walkthroughs Readings Interviews Reviews Checklists Models to check functions and relationships Scenarios Prototypes Simulation Formal inspections

Verification Checking

Cross- referencing Simulation Consistency checks Completeness checks Check for unreachable states of transitions Model checking Mathematical proofs

The table provided lists techniques that can be used validate and verify requirements

Measuring Requirements

Measuring requirements usually focuses on 3 aspects:

1. Product

2. Process

3. Resources

It is also important to track:◦ Requirements size – give us a sense of the size of the system◦ Requirements Change - the number of changes can indicate and

unstable system or an uncertain understanding of the system.◦ These should both be tracked by requirements type.

42

Measuring RequirementEach requirement can also be rated on a scale of 1 to 5

1. You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirement

2. Some elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the past

3. Some elements of this requirement are very different from requirements in the past, but you understand the requirement and can develop a good design from it

4. You cannot understand some parts of this requirement, and are not sure that you can develop a good design

5. You do not understand this requirement at all, and can not develop a design

43

Choosing Specification Techniques

Criteria for selecting specification techniques:◦ Applicability◦ Implementability◦ Testability◦ Checkability◦ Maintainability◦ Modularity◦ Level of Expressability◦ Soundness

44

◦ Verifiability◦ Runtime Safety◦ Tools Maturity◦ Looseness◦ Learning Curve◦ Technique Maturity◦ Discipline

Sources http://www.cse.msu.edu/~cse870/IEEEXplore-SRS-template.pdf

http://modeling-languages.com/how-users-and-programmers-see-each-other/

Software Engineering: Theory and Practice

S. L. Pfleeger and J. M. Atlee

Prentice Hall, Latest Edition

45