CIS224: Software Projects: Software Engineering and Research Methods
Requirements Analysis
1. Software System Analysis
The initial system specification describes the functions of a computer-based
system and the constraints that will govern its development.
The system specification review evaluates the correctness of the definition
contained in the system specification in order to ensure that:
- the scope of the project has been correctly delineated
- functions, performances, and interfaces have been properly defined
- analysis of development risk justify the system
- the developer and the customer have the same perception for the system
2. Requirement Analysis
2.1 Software Requirements Fundamentals
Software Requirements analysis is a step that bridges the gap
between system level software engineering and system design.
The requirements specification as a target product of this software
phase specifies in details the software function performance, the
software interface with other system elements, and establishes design
constraints that the software must meet.
The requirements analysis is performed by the system analyst
who provides the software designers with a representation of
information and functions that can be translated to data,
architectural and procedural design.
2.2 Requirements Analysis- Areas of Effort
Software requirements analysis may be divided into five areas of effort:
a) problem recognition- the goal of the analyst is recognition of the
basic problem elements as perceived by the user/customer;
b) evaluation and synthesis- the analyst must evaluate the flow and
content of information, define and elaborate all software functions,
understand software behavior in context of the events that affect the
system, establish the system interface and design constraints;
c) modeling- the analyst should create models of the system which
serves as a foundation for system design
d) specification- the tasks associated with analysis and specification
strive to provide a representation of software that can be reviewed
and approved by the customer;
e) review
2.3 Requirement Analysis- Principles
a) the information domain of a problem must be represented and understood.
The information domain contains three different views of the data and control
as each is processed by a computer program:
- information structure: represents the internal organization of various
data and control items;
- information content: represents the individual data and control items
that comprise some larger item of information;
- information flow: represents the manner in which data and control
change as each moves through the system.
The basic ingredients of every software are data and control, that is the
data: numbers, characters, images, sound, and the control events both
reside in the information domain of a problem.
b) models that depict system information, and function
should be developed;
c) the software behavior should be represented;
d) the models must be partitioned in a manner that uncovers
detail in a layered fashion;
e) the analysis process should move from essential information
toward implementation detail.
2.4 Software Modeling- Prototyping
Models created during software requirement analysis serve
a number of important roles:
- the model aids the analyst in understanding the information,
function and behavior of the system under development;
- the model becomes the central focus point for review, and,
therefore, is the key to a determination of completeness,
consistency and accuracy of the specification;
- the model becomes the foundation for design, providing the
designer with an essential representation of software that can be
mapped into an implementation context.
The circumstances may require the construction of a prototype model.
A Software Prototyping Scenario
Step 1: Evaluate the software request and determine whether the
software to be developed is a good candidate for prototyping;
Step 2: Given an acceptable candidate project, develop an abbreviated
representation of the requirements;
Step 3: After the requirements model has been reviewed, an abbreviated
design specification is created for the prototype;
Step 4: Prototype software is created, tested and refined;
Step 5: Once the prototype has been tested, it is presented to the customer
who may suggest modifications;
Step 6: Repeat steps 4 and 5 until all requirements are formalized, or
until the prototype has evolved into a production system.
3. Development of a Software Requirements Specification
The software specification may contain graphical and natural language
descriptions of the software requirements.
3.1 Specification Principles
Principle 1: Separate functionality from implementation
Principle 2: Select a process-oriented language
Principle 3: A specification must encompass the system of which
the software is a component
Principle 4: A specification must encompass the environment in
which it operates
Principle 5: A specification must be a cognitive model
Principle 6: A specification must be operational
Principle 7: A specification must be augmentable
Principle 8: A specification must be lously coupled
3.2 Specification Reviews
a) Review at the macroscopic level
Do stated goals and objectives for software remain consistent
with system goals and objectives?
Is information flow and structure adequately defined for the problem?
Do major functions remain within the scope and has been
adequately described?
Are design constraints realistic?
What is the technological risk of development?
b) Review at the microscopic level
Watch out for vague terms
Be sure all items are understood
Be sure stated ranges do not contain unstated assumptions
Look for statements that imply uncertainty
3.3 Software Requirements Specification
I. Introduction
A. Overall Description
B. System Function Statement
C. Software Project Constraints
II. Information Description
A. Information Flow: Use-Case Narratives
B. System Interface
III. Functional Description
A. Functional Partitioning: Courses of Events
B. Functional Contracts
C. Control Specification
D. Design Constraints
IV. Behavioral Description
A. System States
B. Actions
V. Software Validation
A. Performance Bounds
B. Classes of Tests
VI. Appendices
Example: Software Requirements Specification for the POST System
I. Introduction
A. Overall Description:
The goal behind the development of the POST system is to increase the
checkout automation, to support faster, better and cheaper services.
This includes:
 quick checkout for the customer
 fast and accurate sales analysis
 automatic inventory control
B. System Function Statement: Basic Functions
 cashier should login with an id number and password (R1)
 capture purchase information from bar code (R2)
 record the current sale- the items purchased (R3)
 calculate current sale total (R4)
 display a description of the sale (R5)
 handle cash payments (R6)
 handle credit payments (R7)
 handle check payments (R8)
 log completed sales (R9)
 reduce inventory quantities when the sale is committed (R10)
C. Software Project Constraints
This software system will be installed on a computer which is
connected to a bar code scanner.
The system should perform credit payment autorization.
II. Information Description
A. Information Flow
Use-Case Narratives
-----------------------------------------------------------------------------------------------Use case:
Start - up
Actors:
Manager
Type:
…
Description:
A manager powers on a POST in order to
prepare it for use by cashiers, the manager validates the date
and time, after which the system is ready for Cashier use
-----------------------------------------------------------------------------------------------Use case:
Buy Items
Actors:
Customer, Cashier
Type:
…
Description:
A customer arrives at the checkpoint with items to purchase,
the cashier records the purchase items and collects payment,
on completion the customer leaves
Cross References: R1, R2, R3, R4, and R6, R7, R8
------------------------------------------------------------------------------------------------
III. Functional Description
A. Functional Partitioning: Courses of Events
Typical Course of Events for the BuyItems Use-case
--------------------------------------------------------------------------------------------------------------------------------------Actor Action
System Response
1. This use-case begins when the Customer
arrives at the POST checkpoint with
items to purchase.
2. The Cashier records each item.
3. Determines he item price, and adds the item
information to the running sales transaction.
If there is more than one item, the
Cashier enters also the quantity as well.
The description and price of the current item are displayed.
4. On completion of item entry, the Cashier
indicates that enter item is complete.
5. Calculates the sale total and displays it.
6. The Cashier tells the Customer the total.
7. The Customer choose payment type
a. Pay by Cash
b. Pay by Credit
c. Pay bt Check
8. Logs the completed sale
9. Update inventory
10. Generates a receipt
11. The Cashier gives the Customer the receipt
12. The Customer leaves with the purchased items
Typical Course of Events for Pay by Cash
--------------------------------------------------------------------------------------------------------------------------------------Actor Action
System Response
1. The Customer gives a Cash payment
2. The Cashier records the Cash
3. Presents the balance due back to the Customer
4. The Cashier deposits the Cash and
extracts the balance owing
5. The Cashier gives the balance to the Customer
--------------------------------------------------------------------------------------------------------------------------------------Typical Course of Events
Pay by Credit
--------------------------------------------------------------------------------------------------------------------------------------Actor Action
System Response
1. The Customer gives its credit
information for credit payment
2. Generates a credit payment request
and sends it to an external credit authorization service
3. The external credit authorization
service authorizes the payment
4. Receives a credit approval reply
5. Records the credit payment to the accounts system
6. Displays authorization success
---------------------------------------------------------------------------------------------------------------------------------------
B. Functional Contracts
Contracts- these are system documents that describe system behavior in
terms of what the system does, without explaining how it does it.
Contracts are written in declarative style emphasizing what will happen,
rather than how it will be achieved.
-----------------------------------------------------------------------------------------------Contract:
enterItem( UPC: int, qty: int )
Use-case:
BuyItems
Responsibilities:
Enter sale of an item, and add it to sale.
Display the item description and price.
Notes:
Requires fast database access.
Cross References: R1, R2, R3, R4, and R6, R7, R8
Pre-conditions:
UPC is known to the system
Description:
- A new sale instance is created
- The Sale is connected to the POST system
- A sequence of Sales Line Items is created
- The sequence of Sales Line Items is connected to the Sale
- The UPC and quantity are determined
------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------Contract:
MakePayment( amount : double )
Use-case:
BuyItems
Responsibilities:
record the payment, calculate the balance
and print a receipt.
Constraints:
Cross References: R3, R4, R5
Exceptions:
If the sale is not complete indicate error
Description:
- A Payment instance is created
- Payment is connected with Sale
- Payment amount tendered is used to update amount
- The Sale sends amount to Store to complete the sale.
------------------------------------------------------------------------------------------------
IV. Behavioral Description
A. System States
-----------------------------------------------------------------------------------------------States:
Use-case:
BuyItems
Description:
- The system is in state WaitingForSale
- When entering items is initiated it makes a transition
to EnterItems state until a signal endSale
- After receiving endSale signal processing of the Payment starts
- There may be three kinds of payments
- After receiving payment autorization the system returns
to the initial idle state WaitingForSale
------------------------------------------------------------------------------------------------
B. Actions
V. Software Validation
VI. Appendices