Transcript No Slide Title

The Software Development
Life Cycle: An Overview
Presented by
Maxwell Drew
and
Dan Kaiser
Southwest State University
Computer Science Program
Last Time


Project Management Concepts
The Schwan’s Information Services
Deliverables Guide

Project Management Techniques

Project Management in MSF

Project Management in RUP
Session 3: Agenda

The Requirements Process

Schwan’s Requirements Phase

MSF Requirements

RUP Requirements
Requirements


Requirement: a feature of the system or a
description of something the system is
capable of doing in order to fulfill the system’s
purpose
Three kinds of requirements:



those that absolutely must be met
those that are highly desirable but not necessary
those that are possible but could be eliminated
Purpose of Requirements

To establish and maintain agreement with the customers and other
stakeholders on what the system should do.

To provide system developers with a better understanding of the
system requirements.

To define the boundaries of (delimit) the system.

To provide a basis for planning the technical contents of iterations.

To provide a basis for estimating cost and time to develop the
system.

To define a user-interface for the system, focusing on the needs and
goals of the users.
The Requirements Document

The requirements document is the official
statement of what is required of the system
developers

Should include both a definition and a
specification of requirements

It is NOT a design document. As far as
possible, it should set out WHAT the system
should do rather than HOW it should do it
Requirements

Requirements definition


Requirements specification


A statement in natural language plus diagrams of the
services the system provides and its operational
constraints. Written for customers
A structured document setting out detailed descriptions
of the system services. Written as a contract between
client and contractor
Software specification

A detailed software description which can serve as a
basis for a design or implementation. Written for
developers
Requirements definition
1. The software must provide a means of repr esenting and
1. accessing external files created by other tools.
Requirements specification
1.1 The user should be provided with facilities to define the type of
1.2 external files.
1.2 Each external file type may have an associated tool which may be
1.2 applied to the file.
1.3 Each external file type may be represented as a specific icon on
1.2 the user’s display.
1.4 Facilities should be provided for the icon repr esenting an
1.2 external file type to be defined by the user.
1.5 When a user selects an icon repr esenting an external file, the
1.2 effect of that selection is to apply the tool associated with the type of
1.2 the external file to the file represented by the selected icon.
Functional vs. non-functional requirements


Functional: describes
an interaction between
the system and its
environment
Examples:


System shall
communicate with
external system X.
What conditions must be
met for a message to be
sent


Non-functional:
describes a restriction
or constraint that limits
our choices for
constructing a solution
Examples:


Paychecks distributed no
more than 4 hours after
initial data are read.
System limits access to
senior managers.
Types of requirements









Physical environment
Interfaces
Users and human factors
Functionality
Documentation
Data
Resources
Security
Quality assurance
Requirements Readers
Requirements
definition
Client managers
System end-users
Client engineers
Contractor managers
System architects
Requirements
specification
System end-users
Client engineers
System architects
Software developers
Software
specification
Client engineers (perhaps)
System architects
Software developers
Different Perspectives
How developers see users
Users donÕt know what they want.
Users canÕt articulate what they want.
Users have too many needs that are politically
motivated.
Users want everything right now.
Users canÕt prioritize needs.
Users refuse to take responsibility for the system.
Users are unable to provide a usable statement of
needs.
Users are not committed to system development
projects.
Users are unwilling to compromise.
Users canÕt remain on schedule.
How users see developers
Developers donÕt understand operational needs.
Developers place too much emphasis on
technicalities.
Developers try to tell us how to do our jobs.
Developers canÕt translate clearly-stated needs into
a successful system.
Developers say no all the time.
Developers are always over budget.
Developers are always late.
Developers ask users for time and effort, even to the
detriment of the usersÕ important primary duties.
Developers set unrealistic standards for
requirements definition.
Developers are unable to respond quickly to
legitimately changing needs.
Characteristics of requirements







Are they correct?
Are they consistent?
Are they complete?
Are they realistic?
Does each describe something the customer
needs?
Are they verifiable?
Are they traceable?
Requirements Engineering Process

Feasibility study


Requirements analysis


Find out what stakeholders require from the system
Requirements definition


Find out if the current user needs can be satisfied
given the available technology and budget?
Define the requirements in a form understandable to
the customer
Requirements specification

Define the requirements in a detailed form for the
designer
RE Process and its Deliverables
Feasibility
study
Requirements
analysis
Requir ements
definition
Feasibility
report
Requirements
specification
System
models
Definition of
requirements
Requirements
document
Specification of
requirements
Discovering Requirements

Prototyping


Throw Away
Evolutionary


Both referred to as “rapid” prototyping
Use Cases

Will be discussed later
Expressing Requirements

Formal Methods



Axiomatic Definition
Specification Grammars
Mathematical Specifications



Recurrence Relations
Petri Nets
Formal methods have not been
generally accepted by developers
Data Abstraction
Semester record
Semester type
Semester date
Grade-point average
Completed hours
Semester type
(Fall, Spring, Summer)
Address information
Telephone number
Street address
City
State
Postal code
Student record
Name
Student number
Address information
Number of semesters
{Semester record}
Abstract Class Relationships
Transition Diagram (UML)
Entity Relationship Modeling
Example
ERD
Object-Oriented Specifications





Each entity in the system is an object.
A method or operation is an action that can be
performed directly by the object or can happen
to the object.
Encapsulation: the methods form a protective
boundary around an object.
Class hierarchies of objects encourage
inheritance.
Polymorphism: same method for different
objects, each with different behavior
Multiple Inheritance
Choosing a Specification Technique







Applicability
Implementability
Testability/simulation
Checkability
Maintainability
Modularity
Level of abstraction
/expressibility
 Soundness








Verifiability
Run-time safety
Tools maturity
Looseness
Learning curve
Technique maturity
Data modeling
Discipline
Requirements validation


Concerned with demonstrating that the
requirements define the system that the
customer really wants
Requirements error costs are high so validation
is very important


Fixing a requirements error after delivery may cost
up to 100 times the cost of fixing an
implementation error
Prototyping is an important technique of
requirements validation
Requirements checking




Validity. Does the system provide the
functions which best support the customer’s
needs?
Consistency. Are there any requirements
conflicts?
Completeness. Are all functions required by
the customer included?
Realism. Can the requirements be
implemented given available budget and
technology
Validation Techniques
Table 4.6. Requirements validation techniques.
Manual techniques
Automated techniques
Reading
Manual cross-referencing
Interviews
Reviews
Checklists
Manual models to check functions and relationships
Scenarios
Mathematical proofs
Automated cross-referencing
Automated models to enact functions
Prototypes
Questions?
Schwan’s Requirements
Deliverables
Project Requirements


Objective
The objective of the Project Requirements phase is to
identify and document the business requirements for
the project. Business requirements define the vision
for the completed project in terms that the customer
and user can understand and should concentrate on
the business processes rather than technical
processes.
Business Specifications (210)

Objective

Deliverables
The objective of the Business
Specifications is to define the
business rules and give a high level
overview of the way the business
processes are completed. The
DBA’s may be involved at this stage.
Business Event Model
Retention: System
Required:Projects
Optional:Support
Functional Decomposition
Diagram
Retention: System
Deliverable to:Systems Development
Customer (Optional)
Context Diagram
Retention: System
Business Event Document
Retention: System
Entity/Relationship Modeling (220)

Objective
The objective of the
Entity/Relationship Diagram is to
define an Entity/ Relationship model
and approve a Logical Data model with
logical attributes (where database
changes are needed). Cardinalities
will be included to show the business
flow and how the system potentially
will work. DBA’s should be involved in
this step.
Required:Projects
Optional:Support

Deliverable:
Entity/Relationship
Diagram
Logical Data Model
Deliverable to:
Systems Development
Customer (Optional)
Responsibility:Business
Systems Planning
Input/Output Requirements (230)

Objective

Deliverable:
The objective of the
Input/Output Requirements is
to develop the initial input and
output requirements with the
customer’s input and then
review with the customer.
Input Requirements
Output Requirements
Required: Projects
Responsibility: Business
Systems Planning
Optional: Support
Deliverable to:
Systems Development
Customer
SAP Tie: 2.4
Prototyping (240)

Objective
The objective of the prototyping
is to have the customer see the
system and be able to give
suggestions and approve the
potential layout of the system.
This is the beginning of
reviewing potential third party
packages if this is an option.

Deliverable: Customer
Approval (Walkthrough
form?)
Deliverable to:
Systems Development
Customer
Required: <None>
Responsibility: Joint
Responsibility
Optional: Projects, Support
SAP Tie: 2.3,2.5
Detailed Business Specifications (250)

Objective
The objective of the
Detailed Business
Specifications is to detail
the high level Business
specifications’ using a
method such as business
use cases.
Required: Projects
Optional: Support

Deliverable:
Technology Model
Business Use Cases
Business Detail Process
Documentation
Deliverable to:
Systems Development
Customer (Optional)
Responsibility: Business Systems
Planning
SAP Tie: 2.4
Business Test Cases (260)

Objective
The objective of the Business
Test Cases is to have a written
plan to confirm after creation
that the system meets the
business needs of the
customer. This plan should
include a list of functionality
needed at the business level.
Customers should help create
the Business Test Cases.
Required: ProjectsSupport
Optional: <None>

Deliverable: Business
Test Cases
Deliverable to:
Systems Development
Customer (Optional)
Responsibility: Business
Systems Planning
SAP Tie: 2.4
Project Approval

Objective
The objective of the Project
Approval phase is to make sure
that everyone involved agrees on
the requirements and that costs
and estimates are reasonable.
Project Approval Steps





IS Review
Requirements Walkthrough
Customer Review
Development Review
Project Estimation
Statement of Work


Objective
The objective of the Statement of Work is to estimate:
Project Design Phase Only <or> Project Design and Project
Development Phase. The scope of this Statement of Work
will be dependent on how large the project is and if Design
would be better suited to it’s own Statement of Work. A
project Plan should be created and approved with Systems
Development before the SOW is signed.
Questions?