CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Chapter 7 Class will start momentarily. Please Stand By … CS 8532: Advanced Software Engineering

CS 8532: Adv. Software Eng. – Spring 2007Dr. Hisham Haddad

Chapter 7

Class will

start momentarily.

Please Stand By …

CS 8532: Advanced Software Engineering

Dr. Hisham Haddad


Requirements Engineering

Elements of softwarerequirement gathering

Chapter 7


What is Software Requirement?

“A software requirement is a description of the principle features of a software product, its information flow, its behavior, its attributes. In sum, a software requirement provides a blueprint for the development of a software product. The degree of understandability, accuracy, and rigor of the description provided by a software requirement document tends to be directly proportional to the degree of quality of the derived product.”

Source: Software Engineering: An Engineering Approach, by James Peters and Witold Predrycz, Wiley, 2000, Page 118.


Requirements Engineering

Goal: Better understanding of the problem at hand and business impact of the system.

How is it done? Through a process that facilitates a set of defined tasks.

Why do it? To establish a solid foundation for system design and construction.

It is not the solution, but an approach to facilitate the development of a effective solution.


What is Software Requirements Analysis? - 1

Software requirements analysis is process of understanding customer requirements of the software system to be built, and building analysis model of the system (data, functions, behaviour/control flow, interfaces).

The analysis model serves as - basis for creating specifications and software design - means for assessing the quality of the system to be built

This process requires active participation of the customer, and it is crucial step in the development process. The analyst may play different roles - interrogator, advisor, problem solver, and negotiator.


What is Software Requirements Analysis? - 2

The outcome of the process:

- Software Requirements Specifications (SRS). The SRS should be clear, complete, and consistent with customer needs.

- Quality Assurance Plane - set of activities that the project team can follow to ensure software quality throughout the product life cycle (portability, reliability, efficiency, V&V criteria, cost, acceptance criteria, etc…)


System vs. Software Requirements

System requirements analysis, in part, focus on how the software element interacts with other elements of the system (constraints and limitations).

Software requirements analysis focus on the data, functional, and behavioural modeling of the software itself (OOA focuses on classes, relations, and object behaviour modeling).

For software requirements analysis, try to fully answer the following:

- What are the inputs and outputs? - What functions should be defined? - What behaviors (control activities) should be exhibited? - What interfaces are needed?


Why Do Requirements Analysis?

- Identify the customer and work together to negotiate product-level requirements

- Build an analysis model (focus on data, define functions, represent behaviour)

- Prototype areas of uncertainty in the system

- Develop a specification to guide the design and development

- Conduct formal technical reviews to ensure software quality


The Analysis Process

the problemrequirements

elicitation

build aprototype

createanalysismodels

developSpecification Review


Problem Analysis

Problem Analysis

OperationsProductsEnvironment Functions

- People (operators and users)- Devices- Other items affected by the system- business value

- Inputs- Outputs- Items produced for the system

- People functions- Device functions- Other functions needed to produce services and items

- Methods used- operations used to produced items- When operations occur


Real Problems…

- the customer has only a vague idea of what is required.

- the software engineer (analyst) is willing to proceed with the vague idea on the assumption that we'll fill in the details as we go.

- the customer keeps changing requirements.

- the software engineer (analyst) is affected by these changes, making errors in the specifications.

- ?

- ?

- and so it goes ...


Requirements Engineering Tasks - 1

• Inception: Starting the project… where to star? Ask a set of questions that establish

- basic understanding of the problem - the people who want a solution - the nature of the solution that is desired, and - the effectiveness of initial communication and collaboration between the customer and the developer

• Elicitation: Elicit requirements from all stakeholders

• Elaboration: Modeling and refinement (chapter 8) - create analysis model that identifies data, function and behavioral requirements. (in OOA, analysis classes, their services, their relationships).

• Negotiation: Agree on a deliverable system that is realistic for developers and customers.


Requirement Engineering Tasks - 2

• Specification: Can be any one (or more) of the following:– A written document– A set of models– A formal mathematical– A collection of user scenarios (use-cases)– A prototype

• Validation: A review mechanism that looks for– errors in content or interpretation– areas where clarification may be required– missing information– inconsistencies (a major problem with large systems)– conflicting or unrealistic (unachievable) requirements– Conformity issues (with standards set for the product, process,

project)


Requirement Engineering Tasks - 3

• Requirements management: A process to identify, control, and track changes to requirements (similar to SCM)

Traceability tables facilitate requirements management

– feature (of system) traceability table (see figure 7.1, page 148)– source (of requirements) traceability table– dependency (among requirements) traceability table– subsystem traceability table (categorization of requirements)– interface traceability table


Inception

• Identify stakeholders– “who else do you think I should talk to?”

• Recognize multiple points of view

• Work toward collaboration (productive meetings)

• The first questions to ask:

– Who is behind the request for this work?– Who will use the solution?– What will be the economic benefit of a successful solution?– Is there another source for the solution that you need?– … (see page 152)


Elicitation - 1

Initial interview: - break the ice and establish communications channels - scripted (context-free) questions may be used

• understand customer goals and scope the problem• identify stakeholders interested in the system

Sample questions: - What do you expect of the new system? - How will the system help your organization? - Who will be using the system? - Will the system interact with other systems? - etc…


Elicitation - 2

There is not one way for gathering requirements from the client…

The meeting format determines its effectiveness and outcomes.

It is important to listen, but that is not enough! In addition to meeting notes, recording the meetings may be required.

One approach is called Facilitated Application Specification Techniques (FAST) . It is a team-oriented approach to promote constructive and effective communications.


FAST Approach

Guidelines:

• participants must attend entire meeting• all participants are equal• preparation is as important as meeting• all pre-meeting documents are to be viewed as proposed• off-site meeting location is preferred• set an agenda and maintain it• focus on requirements and don’t get mired in technical details

Benefits: many points of view, instantaneous discussion and refinement, concrete step toward developing specs.


Collaborative Approach

Guidelines:• Meetings are conducted and attended by both software

engineers and customers• Rules for preparation and participation are established• An agenda is suggested • A "facilitator" (can be a customer, a developer, or an outsider)

controls the meeting• A "definition mechanism" (can be work sheets, flip charts, or

wall stickers or an electronic bulletin board, chat room or virtual forum) is used

• The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements


Quality Function Deployment (QFD) - 1

Another approach for requirements gathering. Its purpose is to maximize customer satisfaction while developing software requirements that are valuable to the customer. It identifies three types of requirements:

- Normal requirements: what the customer explicitly states and wants in the system.

- Expected requirements: what the customer wants but did not explicitly state assuming we know such requirements.

- Exciting requirements: additional features we can offer.


Quality Function Deployment (QFD) - 2

QFD meeting aspects (deliverables/outcomes):

- Function deployment: determines the “value” (as perceived by the customer) of each function required of the system.

- Information deployment: identifies data objects and control events of the system (based on required functions).

- Task deployment: illustrate system behavior in the target environment.

Value analysis activity determines the priority of system requirements identified in the above deliverables.

Check QFD Institute at http://www.qfdi.org/


Elicitation Work Products

• a statement of need and feasibility (or statement of work).

• a bounded statement of scope for the system or product.

• a list of customers, users, and other stakeholders who participated in requirements elicitation.

• a description of the system’s technical environment.

• a list of requirements (preferably organized by function) and the domain constraints that apply to each.

• a set of usage scenarios that provide insight into the use of the system or product under different operating conditions.

• any prototypes developed to better define requirements.


Use-Cases - 1

Another approach to requirement gathering is Use-cases. Use case are scenarios of system usage by different actors (classes of users and devices).

e.g., student, faculty, and registrar are actors for student registration system.

- Uses-cases are used to: - obtain requirements from the customer - effectively express requirements to the customer

Annotated diagrams are common way to present use-cases.


Use-Cases - 2

Some of the questions a use-case should answer:

- What are the main functions performed by the actor? - What information will the actor acquire, produce or change? - What information does the actor desire of the system? - others…

Check the article “Structuring Use Cases with Goals” at:

http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm

See example page 161.

Retrieve a file use-case1. User clicks file menus2. System displays options new and open3. User clicks option open4. System displays open file window5. User enters/selects file name6. User clicks open button7. System retrieves and opens the file


Analysis Principles - 1

Analysis methods may vary, but they share common principles:

1. Information Domain Analysis and Data modeling:

- define data (and control) items/objects- describe data attributes- establish data relationships and data structures

e.g., student transcript (data object) with different attributes.

2. Function modeling: (iterative process)

- identify functions that transform data objects- indicate how data flow through the system- represent producers and consumers of data objects


Analysis Principles - 2

3. Behaviour modeling:

- indicate different states of the system - specify events that cause the system to change state

4. Partitioning the model:

refine each sub-model to represent lower levels of abstraction - refine data objects - create a functional hierarchy - represent behavior at different levels of details

5. The essence: focus on the problem (requirements) not the implementation details (i.e., answer “what” questions).


SRS StructureTable of Contents1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements (next box) 4. Requirement traceabilityAppendicesIndex

3. Specific requirements 3.1 Interface requirements 3.2 Functional requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

From DoD SRS Standard DI-MCCR-80025A

For SRS details and other templates, check author’s site at

http://www.rspa.com/docs/index.html


Building Analysis Model

Elements of the analysis model: (more in Chapter 8) - Scenario-based elements

• Functional: Processing narratives for software functions• Use-case: Descriptions of the interaction between an “actor”

and the system

- Class-based elements• Implied by scenarios

- Behavioral elements (depict system behavior)• State transition diagram

- Flow-oriented elements• Data flow diagram

SRS Templates and “SRS Components” document will be posted on the Project Page.


Negotiate Requirements

• Identify the key stakeholders– These are the people who will be involved in the

negotiation

• Determine each of the stakeholders “win conditions”– Win conditions are not always obvious

• Negotiate– Work toward a set of requirements that lead to “win-win”

deal


Validate Requirements - 1

• Is each requirement consistent with the overall objective for the system/product?

• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

• Is each requirement bounded and unambiguous?

• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

• Do any requirement conflict with other requirements?


Validate Requirements – 2

• Is each requirement achievable in the technical environment that will house the system or product?

• Is each requirement testable, once implemented?

• Does the requirements model properly reflect the information, function and behavior of the system to be built.

• Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system.

• Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?


Deployment Practices

• Deployment involves system delivery, end-user support, and feedback from end-users.

• Principles:

– Manage customer expectations for each increment– A complete delivery package should be assembled and

tested– A support group should be established before delivery– Instructional materials must be provided to end-users– Buggy software should be fixed first, delivered later– Encourage and collect customer feedback on the system


Suggested Problems

Consider working the following problems from the end of chapter 7, page 173, for practice purpose:

7.1, 7.2, 7.3, 7.4, 7.11, 7.13, 7.16, 7.17

No submission is required. Think about these problems and work them for yourself!


Last Slide

End of Chapter 7

Documents

CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Chapter 7 Class will start momentarily. Please Stand By … CS 8532: Advanced Software Engineering