1

CEN 4020Software Engineering

PPT4: Requirement analysis

2

Process for capturing requirements

Requirements are expressions of desired behavior.•It is what something can do and what states that something can be in. Steps of capturing requirements•Capturing requirements can be broken down into the following parts:•Elicitation – collecting requirements as defined by the user•Analysis – Comprehending and modeling the behavior that is expected•Specification – Recording the behavior of the proposed system•Validation – Ensuring that the specs proposed meet the requirements of the user

3

Process for capturing requirements

The above figure illustrates the process of capturing requirements explained on the previous slide.

4

How users and developers view each other

How developers view users •Users often change their minds because they weren’t sure what they wanted in the first place.How users view developers•Developers often have trouble remembering to talk in very high-level terms to the user. •The developer has to remember that the user doesn’t have a computer science degree.

5

How users and developers view each other

6

Sources of requirements

Sources of requirements

7

Requirement documentation

There are two kinds of requirements documents

•Requirements definition – documents specifying everything the customer wants to accomplish•Requirements specification – reaffirms the requirements as a specification of behavior of the proposed system

8

Importance of requirement analysis

9

Importance of requirement analysis

Take away points from the previous slide –

It is important to note that over 13% of failed projects are caused by incomplete requirements with lack of user involvement being the second most common cause.

Cost of fixing a bug:•$1 to fix a requirement-based problem•$5 to fix the problem at design time•$10 to fix during coding•$20 during unit testing •$200 after delivery of the system

10

Types of requirements

The different forms of requirements are the following:

•Quality requirement – A quality trait that the software solution needs to have (ex.: intuitive/easy to use)•Design constraint – Design decision that decreases number of solutions to the proposed problem•Process constraint – A constraint on the resources that can be used to implement the system.

11

Characteristics of requirements

The following characteristics are wanted of requirements:

•Requirements that are correct

•Requirements that are consistent

•Requirements that are clear

•Requirements that are complete

•Requirements that are achievable

•Requirements that are relevant

•Requirements that can be tested

•Requirements that can be traced

12

Modeling notations

Entity-Relationship Diagram•Graphical notational paradigm for representing conceptual methods

13

Modeling notations

UML Class Diagram•Unified Modeling Language (UML) •Collection of notations used to document software specs and designs

14

Modeling notations

Event Trace•A graphical description of a sequence of events that are exchanged between real-world entities. •Vertical lines represent the timeline for an entity•Horizontal lines represent an interaction between two entities bounding that line

15

Modeling notationsMessage Sequence Chart•An enhanced event-trace notation, with conveniences for making and removing entities, specifying actions and timers, and building traces

16

Modeling notations

State Machine•Graphical description of interaction between the system and environment•Nodes represent states •Edges represent transitions between states

17

Modeling notationsUML State-chart Diagram •Dynamic behavior of objects in a UML class•Shows how instances of a class should change state and how their fields should change value throughout object interaction

18

Modeling notations

Petri Nets•Form of state-transition notation that is used to exemplify activities and their interactions

19

Modeling notationsData flow diagram•Models functionality and flow of data from one function to another

Use case diagram•Depicts observable, user-initialized functionality in terms of interactions between system and environment

20

Modeling notations

Formal methods•Mathematically based specs and design techniques

Decision Table•Tabular representation of a functional spec that maps events and circumstances to corresponding actions

21

Modeling notations

Parnas Table•Collection of table types and abbrev. plans for forming and simplifying functional and relational expressions

First order logic – commonly used to express properties of software requirementsTemporal logic – used to express pending changes over time

22

Modeling notationsObject constraint languageConstraint language that is mathematically precise and high-level (for non-mathematic people)

23

Modeling notationsZ•Requirements spec language that forms set-theoretic definitions of variables into a abstract-data-type model

24

Prototyping requirements

Two approaches to prototyping

Throwaway prototyping •Developing software to learn more about the solution to a problem and the problem itself•Not part of the final product

Evolutionary prototyping •Software developed to comprehend the problem and the solution•Incorporated into the final product

Rapid prototyping comprises both throwaway and evolutionary prototyping because software is developed to learn more about the requirements

25

Prototyping requirementsExamples (Prototypes for a calendar system)

26

Documenting requirementsDocumentation is needed for each team to have the ability to make contributions and ensure the requirements are understood

The definition document is a document of the requirements expressed by the customer

•It is what the customer should see from the final product •Outline the system’s general purpose and scope•The reason behind the proposal for a new system•The important features of a suitable solution•System’s environment•Description of the customer’s potential proposal for a solution to the problem•Assumptions about environment behavior

27

Documenting requirements

The specification document is a document similar to the definition document expressed by the developer

•This document is written in terms of the product’s interface•Description of inputs, outputs, and other topics pertaining to the system interface•Required functionality of the system regarding inputs and outputs•Conditions for the customer’s feature requirements

28

IEEE standard for requirement specification

The IEEE standard provides outlines for organizing the requirements specification by categories including capability and user type

29

Participants in the requirement process

There are many sources that have something to give towards the requirements

•The clients – decision makers•The customers – Important to build something that attracts the customer. May also be a user•The users – Very familiar with the system. May also be the customer.•Domain experts – Knowledgeable of the field in which the system will be used •Market researchers – Know about potential customers•Lawyers – Ensure that no legal boundaries are crossed•Tech experts – Contribute to customer education

30

Validation and verification

The requirements documents act as a contract between the developers and the customer

The requirements should be reviewed to ensure validation and verification

Requirements validation Ensure the requirements definition match customer needs

Requirements verification Ensure that building a system according to the requirements specification document will be a final product that will meet the customer’s requirements

31

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

Validation and verification

32

Measuring requirements

Requirements can be measured in several different ways

Measurements often focus on product, process, and resources

Requirement readiness (see the example below depicting a scale 1 to 5)

33

Choosing a specification languageSelection criteria

Applicability Implement ability TestabilityCheck abilityMaintainabilityModularityAbstraction levelSoundnessVerifiabilityRuntime safetyTools maturityLoosenessLearning curveTechnique maturityData modeling Discipline

34

Choosing a specification language

35

Examples of modeling notations

36

Examples of modeling notations

37

Examples of modeling notations

38

References

Information and illustrations from:

Pfleeger and Atlee, Software Engineering Theory and Practice, 4th Edition.

http://i.imgur.com/ozJipmd.jpg