CS 451 Software Engineering Yuanfang Cai Room 104, University - - PowerPoint PPT Presentation

Drexel University Drexel University

CS 451 Software Engineering

1

Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu

Drexel University

Dilbert On Requirements

2

Drexel University

Introduction

“The hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting system if done

• wrong. No other part is more difficult to rectify

later.” Fred Brooks

 Software engineers often, “Do the wrong thing

the right way.”

3

Drexel University

Introduction

 Every project has requirements engineering.  The start of requirements engineering begins

with it’s stakeholders:

 managers  customers  end-users

 This is where:

 business needs are defined  user scenarios defined  features delineated  project constraints are defined

4

Drexel University

The Process

 The requirement engineering process is

accomplished through the execution of seven distinct functions:

 inception  elicitation  elaboration  negotiation  specification  validation  management

5

Drexel University

Inception

6

Drexel University

Inception

 Projects are usually started with a business need.  Business managers, marketing people, product

managers, etc. define a business case for an idea. They identify:

 the breadth and depth of the market  possibly do a rough feasibility analysis  identify the working description of a project’s scope

 It is important as software engineers that we ask the

right questions.

7

Drexel University

Initiating the Requirement Engineering Process

 Ideally, customers and software engineers work

• n the same team.

 When this is not the case, we:

 Identify the stakeholders  Recognize multiple viewpoints  Work toward collaboration

8

Drexel University

Initiating the Requirement Engineering Process

 What type of questions should we ask?

 What problems will this solution address?  Will special performance issues or constraints affect

the way the solution is approached?

 Are you the right person to answer these questions?

Are you answers “official?”

 Who is behind the request for this work?  Who will use the solution?

9

Drexel University

Initiating the Requirement Engineering Process

 We are often given specifications, implement them

perfectly, but miss the goal of the project or have the goal changed during the course of the design and implementation.

 We must strive to “Do the right thing, the right way.”  This sometimes dictates that we must learn more about

how the customer operates. It helps to educate yourself to the customers business model. Maybe you are familiar with solutions they are not exposed to. Maybe you can combine efforts. Ideas like this must be worked

• ut early in the software engineering process.

10

Drexel University

Elicitation

11

Drexel University

Elicitation

 The goal is to inquire as to:

 what is to be accomplished  how the system or product fits into the needs of the

business

 how the system is to be used on a day-to-day basis

 Sounds simple, reality is it is quite difficult.

12

Drexel University

Elicitation

 Issues include:

 Project scope: What is the boundary of the

system.

 Understanding: The customer/user does not

completely understand what they need. This may be at many levels dealing with a poor understanding of :

 their capabilities and limitations of their computing

environment

 project domain

13

Drexel University

Elicitation

 They also have:

 trouble communicating their needs  omit items that they feel are obvious  specify requirements that conflict with the needs of

• ther customers/user

 specify requirements that are ambiguous or

untestable

14

Drexel University

Eliciting Requirements

 Q & A works effectively only in the initial meeting,

• therwise it’s burdensome.

 Instead, after the initial meeting, replace Q & A with the

eliciting requirement methodology dictated here.

 Teams of stakeholders and developers work together to

elicit requirements

15

Drexel University

Eliciting User Requirements

 It is helpful to create scenarios that identify a

thread of usage for the system to be constructed.

 These scenarios are often called use cases.  Use cases tell a story about how an end user

interacts with the system under a specific set of circumstances.

16

Drexel University

Elaboration

17

Drexel University

Elaboration

 The initial information obtained during inception

and elicitation is expanded and refined.

 Requirements engineering activity focuses on

developing a refined technical model of:

 software functions  features  constraints

18

Drexel University

Elaboration

 Elaboration is an analysis modeling action.  Driven by the creation and refinement of user

scenarios that describe how the end-user (and

• ther actors) will interact with the system.

 Each scenario is parsed to extract analysis

classes

19

Drexel University

Elaboration

 Each scenario is parsed to extract business domain

entities that are visible to the end-user.

 Attributes of each analysis class are defined.  Services required by each class are identified.  Relationships and collaboration between classes are

identified and a variety of supplementary UML diagrams are produced.

20

Drexel University

Negotiation

21

Drexel University

Negotiation

 “Customers want it all and they want it yesterday,”  Customers often want more than can be achieved given

the business resources. This can include a lack of :

 budget  personnel  computing infrastructure

 Also, importantly, customer requirements often

conflict.

22

Drexel University

Negotiation

 The requirements engineer must reconcile these

conflicts with negotiation.

 The negotiation process follows these steps:

 Requirements are ranked by priority.  Conflicts are discussed.  Risks are associated.  Guestimates of development time assigned.

 Requirements are iteratively:

 eliminated (moved to another phase)  combined  modified

23

Drexel University

Specification

24

Drexel University

Specification

 Specification can mean different things to

different people.

 A specification can be written as:

 a written document  a set of graphical models  a formal mathematical model  a collection of usage scenarios  a prototype  any combination of these.

 Some suggest a formal template. Would this

help or hurt?

25

Drexel University

Requirements Document Structure

 Introduction (Requirements Definition)

– Describe need for the system and how it fits with business objectives.

 Functional Requirements

– Describe the services to be provided in detail. May include, data, use

cases, state diagrams, and other graphical representations.

 Non-functional Requirements

– Define constraints on the system and the development process.

 System Evolution

– Define fundamental assumptions on which the system is based and

anticipated changes.

 Glossary

– Define technical terms used.

 Index

26

Drexel University

Requirements Definition

 A statement in natural language of the services

the system provides and its operational constraints.

 Written for customers.

27

Drexel University

Requirements Definition

 Example: Thera Wii from 2009

There is an emerging trend toward using video games as a means of increasing patient engagement in physical therapy. This trend is primarily driven by the newest generation of consumer console systems which use motion-based controls. However, clinical research into the efficacy of these systems is hindered by the inability to automatically collect data from systems and software which were not intended for this purpose. We will create a new piece of software that will give researchers the ability to experiment and quantitatively assess the value of game-based therapy. This software will provide an extensible framework for games or interactive experiments as well as an example suite of activities. The key aspect of this framework will allow researchers to easily gather data from motion-based input controls such as the Wii Remote. Various reporting methods and analysis tools will be provided for the gathered data.

28

Drexel University

Requirement Specification Review

 Requirements may be functional or non-functional  Functional requirements describe system services or features.  The key is to remember it is about the WHAT not the HOW of

your project.

 One exception to this, IMHO, is the user interface. We prefer to see

most of it dictated in the requirements document, because it is a great tool to help the end-user understand what you are developing.

29

Drexel University

Senior Design -- Requirement Specification Review

 Functional Requirement Examples

r3.1 The software shall keep a persistent set of menus at the top of the Therapy/Prole window. Priority 1 r3.2 The software shall list the menu options as text horizontally across the top of the window. Priority 1 r3.3 File Menu r3.3.1 The software shall display a drop down menu when the \File" menu is clicked on. Priority 1 r3.3.2 The software shall have an \Import Therapies..." option in the File menu. Priority 1 r3.3.3 The software shall have an \Export Therapies..." option in the File menu. Priority 1 r3.3.4 The software shall have an \Import Profiles..." option in the File menu. Priority 1 r3.3.5 The software shall have an \Export Profiles..." option in the File menu. Priority 1 r3.3.6 The software shall bring up the appropriate import or export dialog if any of the Import or Export menu options is clicked on (see [4.3.6]). Priority 1 r3.3.7 The software shall have a \Quit" option in the File menu. Priority 1 r3.3.8 The software shall exit the program if the \Quit" option is clicked by the user. Priority 1

30

Drexel University

Senior Design -- Requirement Specification Review

 Each Spec item

 Atomic  non-ambiguous  In active tense  traceable (indexed)

 Overall SRS

 Consistent  Complete.  Non-ambiguous  Traceable

31

Drexel University

Senior Design -- Requirement Specification Review

 Non-functional requirements is a constraint on the system or on the

development process. This may include some description of the HOW.

 Non-functional requirements may include:  security standards  system properties and constraints e.g., reliability, response time

and storage requirements. Constraints are I/O device capability, system representations, etc.

 process requirements may also be specified mandating a

particular CASE system, programming language or development method.

 Non-functional requirements may be more critical than functional

• requirements. If these are not met, the system is useless.

32

Drexel University

Validation

33

Drexel University

Senior Design -- Requirement Specification Review

 How do you Validate that you’ve done a good job?  You might think that quality is hard to quantify during

requirements engineering. After all, how can you determine if what the end-user/customer is telling you is correct?

 However you can check for:  ambiguity  conflicts  omissions (some, obviously not all)

34

Drexel University

Requirement Engineering

 Traceability  Every requirement is given a unique identifier. This helps

with traceability.

 You can include any of the following diagrams:

 Source traceability table: identifies the source of each

requirement

 Dependency traceability table: identifies how requirements are

related to another

 Subsystem traceability table: Categorizes requirements by the

subsystems they govern.

 Interface traceability table: relates requirements to both internal

and external interfaces.

35

Drexel University

Specification

 A template may be good for inexperienced

requirement engineers, but IMHO doesn’t provide enough flexibility.

 I feel a combination of approaches is required,

to what level of each depends largely on a the project.

 Complete coverage in a formal mathematical

model is difficult to create let alone read and maintain.

36

Drexel University

Validation

 The previous work products are accessed for

quality during the validation step.

 You might think that quality is hard to quantify

during requirements engineering. After all, how can you determine if what the end- user/customer is telling you is correct?

 However you can check for:

 ambiguity  conflicts  omissions (some, obviously not all)

37

Drexel University

Management

38

Drexel University

Management

 Requirements constantly change, and therefore must be

managed.

 Every requirement is given a unique identifier. This helps

with traceability.

 You can include any of the following diagrams:

 Source traceability table: identifies the source of each

requirement

 Dependency traceability table: identifies how requirements are

related to another

 Subsystem traceability table: Categorizes requirements by the

subsystems they govern.

 Interface traceability table: relates requirements to both internal

and external interfaces.

39

Drexel University

Sample Traceability Table

40

Drexel University

SRS Review Criteria

41

 Meet Customer Needs  Implementable  Omissions:



For example, the chess game SRS should at least have the following functions:



Enter the Game



Play the Game



Exit the Game



Save/reload the Game

 Inconsistencies  E.g. functions shown in use cases are not specified.  Ambiguities:  E.g. “the size of the input file shouldn’t be too large”  Traceability