Intro To Software Engineering

An Introduction to Software Engineering
Spring Semester, 2008 Copyright Reserved
Requiremnent Engineering
Review of Last Lecture (1/2)

Software lifecycle
From the viewpoint of software Typical lifecycle of software
Software process
From the viewpoint of software development Provide well-defined steps to develop software
Copyright Xinjun Mao
Review of Last Lecture (2/2)

Software development process model
Waterfall model Prototyping model Incremental model RAD model Spiral model
Merits and draws CASE tool and environment

Improve the quality and efficiency of software development
Copyright Xinjun Mao 3
Todays Topic
How to get the customers requirements?
Chapter 7 in Textbook
Requirement Engineering
Prof. Mao Xinjun xjmao@nudt.edu.cn Tel: 0731-4573649 Department of Computer Science and Technology, National University of Defense Technology
Agenda
What is Requirement Engineering? Task and Process of Requirement Engineering Requirement Engineering Technology Software Requirement Specification and Review Summary
Questions?
If you are required to develop a library information software system, what will you do firstly?
What functions that the system may have? What behaviors that the system may have? What performances that the system may have? What is the scope and boundary of the software?
Software Requirement
To understand customers requirements about the software to be developed is extremely important Software requirement ()
Customers needs about the developed software, including functions, performance, design constraints, schedule, etc.
Sample of software requirements

Function: borrow book, renew book, Performance: the time of query book must be lower 1 second Constraints: software should be deployed and run under windows OS Schedule: development period is 6 months
Requirement Engineering
What is requirement engineering? ()
The process to obtain customers or end-users ( ) requirements of software Encompasses a set of tasks that lead to an understanding of software requirements Helps software engineers to better understand the problem they will work to solve
Who Does IT?

Software Engineers Analysts () Managers Stakeholders ()
Customers End-users
10
Importance of Requirement Engineering
Basis and precondition of software development

If you do not know what the problems are, you will have no way to know how to solve Without it, the resulting software has a high possibility of not meeting customers needs Establishes a solid base for design and construction
Standard to check whether the developed software meets customers or end-users requirements
11
Complexity of Requirement Engineering
Customers are unable to express requirements explicitly

Typically, they can not tell you what they want clearly
The requirements that customers or end-users present are often

incomplete inaccurate inconsistent
Software requirements are often extremely complex and large scale

Problems and Challenges

If the above problems can not be solved, the developed software will be incorrect
Lost the desired functions of customers Implemented functions are not the right ones that customers or end-users want
Therefore, technologies and methods are necessary to support requirement engineering
13
Agenda
What is Requirement Engineering? Task and Process of Requirement Engineering Technology of Requirement Engineering Software Requirement Specification and Review Summary
Task of Requirement Engineering

Obtain and understand software requirements in a complete, consistent and accurate way, and generate software requirement specification (SRS) document
15
Scope of Requirement Engineering

Communication Planning Modeling
Analysis of requirements Design of software Requirement Requirement Engineering Engineering
Construction
Coding Testing
Deployment
Process of Requirement Engineering

Requirement engineering is completed through the following seven activities
Inception () Elicitation () Elaboration () Negotiation () Specification () Validation () Management ()
Inception (1/2)
Purpose
Identify and discuss with stakeholders Anyone who benefits in a direct or indirect way from the system which is being developed: Customers, end-users, consultants, product engineers, software engineers
Approach
Find and create stakeholders list Work toward collaboration to support elicitations Ask: who else do you think I should talk to? to find more
Result
A list of stakeholders
Inception (2/2)
Principle
Related Complete
Questions when interacting with stakeholders

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?
19
Elicitation (1/3)
Purpose
Elicit requirements from all stakeholders Identify the problem Define the scope of problem Propose elements of the solution Negotiate different approaches, and Specify a preliminary set of solution requirements
20
Elicitation (2/3)
Approach
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" is used, e.g., work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum
Elicitation (3/3)
Result: elicitation work products
A statement of need and feasibility A bounded statement of scope for the system or product A list of stakeholders who participated in requirements elicitation A description of the systems technical environment A list of requirements 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
Elaboration (1/2)
Purpose
Create a refined analysis model of software functions, features, and constraints for analyzing
Approach
Modeling, refinement Scenario-based
Functionalprocessing narratives for software functions Use-casedescriptions of the interaction between an actor and the system
Elaboration (2/2)
Approach
OO-based Behavior-based: state diagram Flow-oriented: data flow diagram
Result
Requirement analysis model of software, which defines the informational, functional and behavioral domain of problem
Negotiation
Purpose
Conflict requirements Unpractical requirements with limited resources Agree on a deliverable system that is realistic for developers and customers
Approach
Identify the potential conflict and unpractical requirements Rank requirements and discuss conflicts Reconcile these conflicts through negotiation Eliminate, combined and modified requirements
Result: agreed software requirements

Specification
Purpose
Create the documents of software requirements
Approach
A written document A set of models A formal mathematical A collection of user scenarios (use-cases) A prototype
Result
Software requirement specification
Validation (1/3)
Purpose
To find the errors or missing information in SRS
A review mechanism that looks for

Errors in content or interpretation Areas where clarification may be required Missing information Inconsistencies (a major problem when large products or systems are engineered) Conflicting or unrealistic (unachievable) requirements.
Result
Validated software requirement specification
Validation (2/3)
Questions when validating
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 requirements conflict with other requirements?
Validation (3/3)
Questions when validating (cont.)
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?
Management
Requirement management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds
Each requirement is assigned a unique identifier Feature traceability table Source traceability table Dependency traceability table
Agenda
31
Requirement Elicitation (1/3)

Problem
Stakeholder
Com m unication
Analyst
32
Meeting
33
Observation
34
Joint Team
Joint Team
Stakeholders Analysts Software engineers
Purpose
Communication Cooperation
35
Requirement Modeling and Analyzing

Problem Decomposition () Abstract () Modeling () Multiple Viewpoints () Prototype ()
36
Problem Decomposition
What is problem decomposition?
Decompose big problem into small problems Decrease and control problem complexity
Sample of problem decomposition

Reader management Book management Book borrow
37
Abstract (1/2)
What is abstract?
Catch the related parts and discard the unrelated parts To grasp the essence and core of problem
Sample of abstract
Appearance
Face
Cloth Appearance Abstract

38
Yellow
Big
Abstract (2/2)
Abstract of reader (related parts)
Name Department Photo Type Email Telephone Mobile .
Abstract of reader (unrelated parts)

Height Age Thesis Father Blood Supervisor
39
Modeling (1/3)
What is model of system
Model is the simplification of the real system and it encompasses the related parts of system, ignores the unrelated parts of system Software requirement model describes the requirement of system to be developed in an accurate way
Why modeling
Simplify the description and analysis of software requirement Specify the software requirements from multiple viewpoints and different levels
Modeling (2/3)
Methods for requirement modeling
Data flow requirement modeling Object-oriented modeling
41
Modeling (3/3)
Sample of modeling: Data Flow Diagram
42
Multiple Viewpoint
What is multiple viewpoint
To describe and analyze software requirements from multiple viewpoints and different levels
What is multiple viewpoint

To grasp the customers requirements in a complete and clear way
43
Prototyping
What is prototype?
Prototype is the intuitive and simple model of systems to be developed. It mainly focuses on the operation style, process and interface.
Why prototype?
Prototype as interaction media between developers and customers Prototype can easily find the problems of software requirements
44
Prototype Method
Initial Requirement
Rapid Design Suggestions Requirements
Prototype
Evaluate Prototype
45
Agenda
46
Software Requirement Specification

Software requirement specification
Functions and Behaviors
E.g., borrow book, renew book
Performances
Response time should be less than 1 second
Design constraints
Running under Windows XP
Others
Schedule: 6 months
Standard for SRS

Standardization of SRS
International Government Enterprise Military,
Sample template of SRS

See (doc)
Review of SRS
Reviews is necessary before SRS is to be submitted formally to designers Who participate in the reviews
Customers and end-users Requirement analysts Software designer
49
Principles of Review
Correct Consistent Complete Verifiable Understandable Modifiable Traceable
Agenda
51
Summary (1/2)
To capture accurate, consistent and complete requirements are extremely important for developing software Requirement engineering covers seven activities
Inception, elicitation, elaboration, negotiation, specification, validation, management
Technologies are necessary to support the requirement engineering

Modeling, abstract, decomposition, prototyping, etc.
Summary (2/2)
Software requirements should be written as a document software requirement specification Software requirement specification should be reviewed before it is delivered to designer
Customers, end-users, requirement analysts, software designers, etc. should participate in the reviews Quality of software requirements should be considered
Assignment
See assignment1 (doc)
54
Next Lecture
Building Requirement Model with Data Flow Oriented Technology Chapter 8.6 in Textbook
55
Introduction to Software Engineering
Q&A
Practice, Practice and Practice


Intro To Software Engineering

Uploaded by

Copyright:

Available Formats

You might also like

Intro To Software Engineering

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro To Software Engineering

Uploaded by

Copyright:

Available Formats

An Introduction to Software Engineering

Spring Semester, 2008 Copyright Reserved

Review of Last Lecture (1/2)

Copyright Xinjun Mao

Review of Last Lecture (2/2)

Merits and draws CASE tool and environment

Copyright Xinjun Mao

Copyright Xinjun Mao

Sample of software requirements

Copyright Xinjun Mao

Who Does IT?

Copyright Xinjun Mao

Importance of Requirement Engineering

Basis and precondition of software development

Copyright Xinjun Mao

Complexity of Requirement Engineering

Customers are unable to express requirements explicitly

The requirements that customers or end-users present are often

Software requirements are often extremely complex and large scale

Problems and Challenges

Therefore, technologies and methods are necessary to support requirement engineering

Copyright Xinjun Mao

Task of Requirement Engineering

Copyright Xinjun Mao

Scope of Requirement Engineering

Process of Requirement Engineering

Questions when interacting with stakeholders

Copyright Xinjun Mao

Copyright Xinjun Mao

Result: agreed software requirements

A review mechanism that looks for

Copyright Xinjun Mao

Requirement Elicitation (1/3)

Copyright Xinjun Mao

Requirement Elicitation (2/3)

Copyright Xinjun Mao

Requirement Elicitation (3/3)

Copyright Xinjun Mao

Copyright Xinjun Mao

Requirement Modeling and Analyzing

Copyright Xinjun Mao

Sample of problem decomposition

Copyright Xinjun Mao

Cloth Appearance Abstract

Copyright Xinjun Mao

Abstract of reader (unrelated parts)

Copyright Xinjun Mao

Copyright Xinjun Mao

Copyright Xinjun Mao

What is multiple viewpoint

Copyright Xinjun Mao

Copyright Xinjun Mao

Rapid Design Suggestions Requirements

Copyright Xinjun Mao

Copyright Xinjun Mao

Software Requirement Specification

Standard for SRS