BIO
PRESENTATION
PAPER
W15
September 29, 2004 3:00 PM
DISCOVERING THE TRUE
SOFTWARE REQUIREMENTS
Paul Desantis
Hughes Network Systems
Better Software Conference & EXPO
September 27-30, 2004
San Jose, CA USA
Paul DeSantis
Throughout Paul’s career, he has been involved in requirements analysis both formally
and informally. This ranged from simple analysis of software enhancements to collecting
requirements for a whole new product. Recently, he has become more involved in
requirements management. His own hybrid requirements analysis based on academics
helped him win Best Sales Team Win and Achievement awards and has been credited
in making other sales.
Paul has also performed many sales presentations to potentials clients in several
different countries, taught an engineering seminar in and India, taught numerous internal
classes on systems analysis, Unified Modeling Language, data-link protocol conversion
techniques, and IBM System Network Architecture. As a volunteer, he spoke to
Frederick County, Maryland public school students for National Engineers Week and
taught merit badge courses at the Boy Scouts National Jamboree(s).
Paul holds a B.S. in Engineering Technology and a M.S. in Technology Management.
He has been employed with Hughes Network Systems for the past fifteen years.
Discovering the True Software
Requirements
Paul DeSantis
1HNS-32099 7/15/2004
Better Software Conference 2004
Presentation Objectives
This paper discusses an academic approach to
requirements analysis. Topics covered will be:
•
•
•
•
•
•
•
•
Brief overview of systems analysis
Understanding the stakeholders and their perspectives
Discovering requirements
Documenting and expressing requirements
Avoiding over analysis
Prioritizing requirements
Knowing requirements conflict
Defining open systems
2HNS-32099 7/15/2004
Better Software Conference 2004
What are Requirements and What
Makes Them Important?
• What are requirements?
– This paper will simply define requirements as the needs of the
stakeholders. One could also view requirements as solving
problems.
• What makes requirements important?
– Mistakes made in the front end of the development life cycle
can have substantially negative impacts on the system design’s
total cost, time schedule, and customer satisfaction
– It is the stakeholders’ needs that become the originating
requirements—the business requirements. These originating
requirements are major inputs for almost every design function
(Buede, 2000).
– This is why requirements are important, because they influence
the entire development life cycle.
3HNS-32099 7/15/2004
Better Software Conference 2004
Overview of Systems Analysis
• Scope Definition Phase
– Answers the question, “Is it worth looking at this project?”
– Deliverables: Brief Statement of Problem and Solution and
Problem Statement Matrix
– Tasks: Identify baseline problems and opportunities, Negotiate
baseline scope, Assess baseline project worthiness, Develop
baseline schedule and budget, Communicate the project plan
• Problem Analysis Phase
– Answers the question, “Are the problems really worth solving?”
– Deliverables: Problems, Opportunities, Objectives and
Constraints Matrix, a Cause and Effect Diagram, and PIECES
worksheet
– Tasks: Understand the problem domain, Analyze problems and
opportunities, Analyze business processes, Establish system
improvement objectives
4HNS-32099 7/15/2004
Better Software Conference 2004
Overview of Systems Analysis
• Requirements Analysis Phase
– Answers the question, “What do the users need and want
from a new system?”
– Deliverables: Use cases glossary, diagrams, and narratives
– Tasks: Identify and express system requirements, Prioritize
systems requirements
• Logical Design Phase
– Performs systems modeling or prototyping
– Deliverables: A prototype of solution (product), or Unified
Modeling Language (UML), data and process models
– Tasks: Structure functional requirements, Prototype
functional requirements, Validate functional requirements,
Define acceptance test cases
• Decision Analysis Phase
– Identify options, analyze options, then sell best solution
– Deliverables: Feasibility Analysis Matrix, System Proposal
5HNS-32099 7/15/2004
Better Software Conference 2004
Phase One Scope Definition
• The scope definition phase assesses the project worthiness by
answering, “Is it worth looking at this project?” To help assess,
a problem statement matrix is used (Whitten, 2004).
• Caution about builder-architected systems. Solutions for these
systems are looking for a problem, making them vulnerable to
working on the wrong problem (Maier, 2002).
• Sample problem statement matrix:
Brief Statements
of Problem,
Opportunity, or
Directive
List of
statements
identifying the
problem,
opportunity, or
directive
6HNS-32099 7/15/2004
Urgency
Visibility
Time frame to
solve
problem,
rating scale
What degree
would the
solution be
visible to
customers,
rating scale
Annual Benefits
Dollar estimate
(best guess)
of savings or
increase in
revenue
Priority or Rank
Rating scale
Proposed
Solution
At this phase,
possible
solutions
expressed in
simple terms
Better Software Conference 2004
Phase Two Problem Analysis
Two artifacts completed in the problem analysis phase, which are
used later, are the Problems, Opportunities, Objectives, and
Constraints Matrix and the Performance, Information, Economics,
Control, Efficiency and Service (PIECES) framework.
Cause-and-Effect Analysis
Problem or Opportunity
Problem statement
Causes and Effects
Possible causes of the
problem, or the
symptoms
Systems Improvement Objectives
System Objective
What you expect to
achieve
System Constraints
Something that will
reduce your flexibility
in defining an
improvement
Performance
A. Throughput
B. Response
Control (and security)
A. Too little security or control
B. Too much security or control
Information (and data)
A. Outputs
B. Inputs
C. Stored Data
Efficiency
A. People, machines, or computers waste time
B. People, machines, or computers waste materials and supplies
C. Effort required for tasks is excessive
D. Material required for tasks is excessive
Economics
A. Costs
B. Profits
Service
A. System produces inaccurate results
B. System produces inconsistent results
C. System is not easy to use
D. System is incompatible with other systems
7HNS-32099 7/15/2004
Better Software Conference 2004
Phase Three Requirements Analysis
Identifying the Stakeholders
• One of the primary roles of Systems Analysis in the
development of systems is to collect the needs from
the stakeholders, and bridge communications gap
between non-technical and technical stakeholders.
Who are these stakeholders and what role do they
perform?
– System owners
• These stakeholders are usually middle to executive level
managers who are concerned about cost and value
– Systems users
• These stakeholders are concerned about getting the job
done using the functionality of the system along with its
ease of use and learning
8HNS-32099 7/15/2004
Better Software Conference 2004
Identifying the Stakeholders
– Systems users (Cont.)
• Internal (employees)
• External (suppliers, customers)
– System designers
• Technical specialists who translate the business
requirements into technical solutions by designing the
various system components
– System builders
• Technical specialists who construct the system according to
the system designer’s specifications
9HNS-32099 7/15/2004
Better Software Conference 2004
Understanding the Stakeholders
and Their Perspectives
• Stakeholders and their perspectives can be understood using
building blocks for an information system.
• Knowledge building blocks
– System owners’ view of knowledge is to identify business
entities and rules, and is interested in the information that adds
new business knowledge about these entities and rules.
– System users’ view of knowledge will provide data
requirements, which are an extension of business entities and
rules. Users are concerned about the details (attributes) of
entities and rules.
– System designers’ view of knowledge will translate the system
users’ business data requirements into a database design.
Their concern is with database technology and view of
knowledge consists of data structures, fields, indexes, etc.
– System builders’ view of knowledge will construct the actual
database structure using tools and techniques (e.g., SQL),
based on the designers’ ideas.
10HNS-32099 7/15/2004
Better Software Conference 2004
Understanding the Stakeholders
and Their Perspectives
• Process building blocks
– System owners view processes in the form of business
functions (sales, service, manufacturing, shipping, receiving,
and accounting). These business functions can be described
as many events and responses, e.g.,
• Event - Customer submits order.
• Response - Shipping department ships order.
– System users view processes as the work required to carry out
the business function’s response to an event, in accordance
with policy.
– System designers view processes as determining which
processes (work) can be automated and how best to automate
them using available technology.
– Systems builders view processes from the perspective of
programming languages in order to build the application
program.
11HNS-32099 7/15/2004
Better Software Conference 2004
Understanding the Stakeholders
and Their Perspectives
• Communication building blocks
– System owners view communication as the business units of
employees, customers, and external businesses that interface
with the new system. Also, where are they located? In
addition, what type of other systems will interface?
– System users view communication as it is concerned with the
basic interaction with the system. The inputs and expected
outputs, and the details of each are important. Note: Users will
want the look and feel of their favorite PC tools (e.g., Excel).
– System designers view communication as it is concerned with
the interface specifications and user dialogue (movement
among windows), which can be difficult to design. Graphical
design specialist and human-computer interface specialist may
help with design.
– System builders view communication to construct system-tosystem and system-to-user interfaces using middleware and
graphical user interface technology.
12HNS-32099 7/15/2004
Better Software Conference 2004
Discovering Requirements
Now that the stakeholders are known and their views and
concerns understood, the system analyst next identifies their
needs. Requirements discovery has multiple techniques
(Whitten), each with advantages and disadvantages.
1. Sample Existing Documentation, Forms, and Files
• This technique will collect various types of existing documents,
forms and reports, perhaps too many to study. In this case, a
sampling technique of some sort should be utilized. Some of
the information that should be retrieved is:
– The Problems, Opportunities, Objectives, and Constraints
Matrix and PIECES artifacts
– Organizational charts to identify stakeholders that will be a
source of information
– Documents describing business functions and policies
– Documents containing design information about
predecessor system, operator manual, and work instructions
13HNS-32099 7/15/2004
Better Software Conference 2004
Discovering Requirements
2. Research
• This technique involves having the system analyst research the
problem being solved for background information and
understanding the problem domain. The analyst would
research trade journals, industry books, etc. Also, because not
all problems are unique, it may already be solved.
3. Observation of the Work Environment
• This technique is simply watching the system in action. This is
one of the more effective data-collection techniques. The
system analyst will observe the people and activities to learn
their needs, and will also verify information collected from other
techniques.
• Requires preparation and determination of how to capture info.
• Get permission, do not interrupt productivity, keep a low profile,
and know that some people will behave differently when
watched. It is best to single out who would be observed,
including where, what, when, why, and how.
• Review observation notes with the person to confirm if correct.
14HNS-32099 7/15/2004
Better Software Conference 2004
Discovering Requirements
4. Questionnaires
• Determine what facts must be collected and from whom.
• Based on the facts sought, develop appropriate question
format for no more than three sentence answers.
• Inspect questions for possible misinterpretation.
• Test the questions on a small group first.
• There are two basic questionnaire formats.
– Free-format: Allow users to exercise more freedom in their
answers. Use simple sentences that do not leave room for
different interpretations.
– Fixed-format: More rigid, requiring the respondent to select
from a predetermined list of answers. Questions types:
• Multiple choices. Can allow for free-format responses.
• Rating. These are used to gather opinions.
• Ranking. These allow respondents to rank a set of
answers in order of preference.
15HNS-32099 7/15/2004
Better Software Conference 2004
Discovering Requirements
5. Interviews
• This technique uses personal interviews between the analyst
and system users (not the system owners).
• This approach has many advantages and is looked upon as the
most common and important technique for collecting
requirements.
• Gets users personally involved. Before conducting interviews,
collect as many facts as possible.
• Types of interviews and questions formats:
– Unstructured interview: Analyst asks general open-ended
questions and let interviewees direct conversations or respond
in anyway. This may allow conversations to get off track.
– Structured interview: Analyst asks specific closed-ended
questions to solicit specific information, then follows up with
another question for further clarification. Answers are
restricted to specific choices or short-direct responses.
16HNS-32099 7/15/2004
Better Software Conference 2004
Discovering Requirements
6. Discovery Prototyping
• This technique involves building a prototype for the purpose
of identifying requirements by having users test the working
model and provide feedback.
7. Joint Requirements Planning (JRP)
• JRPs are group work sessions and are a formal alternative to
numerous interviews. JRPs are becoming common,
especially when required to reach a consensus on
requirements. Unlike interviews, JRPs last several days and
have the system owners present. If executed correctly, JRPs
can resolve conflicting information and requirements and
obtain a consensus among users and managers.
17HNS-32099 7/15/2004
Better Software Conference 2004
Documenting and Expressing
Requirements
•
After requirements are identified, they must be documented and
analyzed. Expressing the requirements can be done using
natural language sentence or use-case analysis.
• Natural Language Sentence (Buede)
– Most projects will write requirements using simple sentences.
The statements structure shall be broken down into the
following components:
1. Subject (the system of interest)
2. Verb phrase usually starting with the word shall, or other
applicable words:
• Shall indicates limiting nature of the requirement.
• Will indicates a fact.
• Should indicates a goal.
3. Object, which describes the input, output, etc.
4. Minimal acceptable threshold with units (optional).
5. Conditions that would make the statement true (optional).
18HNS-32099 7/15/2004
Better Software Conference 2004
Documenting and Expressing
Requirements
• Natural language sentence
– Example of a requirement statement: “The system shall prompt
the user with a login screen upon touch of the keyboard.”
• Use the following rules when writing requirements:
– Do not use a compound predicate. This will cause problems
with tracing in requirements management. Example: The
system shall fit.., weigh.., cost.
– Do not use negative predicates, which will describe what the
system is not to do. Example: The system shall not…
– Do not use and/or, which provide designers with a choice.
– Do not start a requirement with a conditional statement. E.g., If
the input is…the system shall... Instead, conditions that make
the requirement true should be placed at the end.
– Do not use ambiguous verbs such as maximize or minimize.
– Do not use ambiguous adjectives. Most common ones are:
adaptable, adequate, easy, flexible, rapid, robust, sufficient,
supportable, and user-friendly.
19HNS-32099 7/15/2004
Better Software Conference 2004
Documenting and Expressing
Requirements
• Use-case analysis
– In software engineering, requirements discovered are
also expressed using use-case analysis. Use-case
analysis is a modeling process part of the UML
standard.
– This technique will produce a use-case glossary, usecase model diagram, and use-case narrative artifacts.
– Modeling requirements is not effective for expressing
performance (Maier), which is a system category of the
PIECES framework.
• The use-case diagram graphically depicts the system
and its interactions within the given environment by
using a collection of modeling elements. These three
elements are (Fowler, 1999):
20HNS-32099 7/15/2004
Better Software Conference 2004
Documenting and Expressing
Requirements
– Use-cases: The sequence of events a system
performs to yield an observable result.
– Actors: Actors are users of the system, either for
input or output. These users exist outside the
system.
• Primary: This user is the one primarily benefiting from
the use-case execution by receiving an output.
• Primary System Actor: This user directly interfaces
with the system to initiate the transaction.
• External Server Actor: This user responds to a request
from a use-case.
• External Receiver Actor: This user is not the primary
actor but also receives something of value from a usecase output.
21HNS-32099 7/15/2004
Better Software Conference 2004
Documenting and Expressing
Requirements
– Relationships: A use-case can have relationships between
an actor and other use-cases.
• Include: Provides common functionality
• Generalization: Almost common steps among usecases
• Extend: An alternative or exception to normal behavior
Order Subsystem
Maintenance Staff
<<includes>>
Check Out
Equipment Available Status
System
Check Out Receipt
Check In
22HNS-32099 7/15/2004
Equipment Depot
Better Software Conference 2004
Documenting and Expressing
Requirements
• Use-case glossary
– This tabular list has the use-case names, a one-paragraph
description for each case, and the participating actors and roles.
Use-Case Name
Use-Case Description
Participating Actors and Roles
Check Out
This use-case describes the event of a
maintenance staff member requesting use of
equipment by filling out a form containing type
of equipment, reason, job number, etc.
Maintenance Staff (primary)
Equipment Availability Status (external
server)
Check Out Receipt
This use-case describes the event of the
system printing a completed Check Out form.
System (primary)
Maintenance Staff (external receiver)
Equipment Depot (external receiver)
Check In
This use-case describes the event of
equipment depot staff receiving checked out
equipment from maintenance staff, putting
equipment physically back into depot, and then
updating system.
Equipment Depot Staff (primary)
Equipment Availability Status
This use-case describes the event of notifying
the check out use case of equipment already
checked out or on order.
System (primary)
Check Out (external receiver)
23HNS-32099 7/15/2004
Better Software Conference 2004
Documenting and Expressing
Requirements
• The use-case narrative documents all use-cases by expanding
them into a step-by-step description. Some fields include
(Whitten):
– Precondition: This is a constraint on the state of the system
before the use-case can be executed.
– Trigger: This is the event that initiated the execution of the usecase.
– Typical course of events: This is the normal sequence of
activities performed by both actor and the system to satisfy the
objective of the use-case.
– Alternative courses: This documents the behavior of the usecase in an exception or variation to the typical course of events.
– Business rules: These specify policies and procedures of the
business for the system to abide by.
– Assumptions: Any assumptions that were made by the author
when writing the narrative.
24HNS-32099 7/15/2004
Better Software Conference 2004
Documenting and Expressing
Requirements
USE CASE NAME:
Check-Out Equipment
USE CASE TYPE
USE CASE ID:
Business Requirements:
PRIORITY:
High
SOURCE:
Cause & Effect Analysis and Personal Interviews
PRIMARY BUSINESS ACTOR:
Maintenance Staff
OTHER PARTICIPATING ACTORS:
•
•
Equipment Depot
System
OTHER INTERESTED STAKEHOLDERS:
•
Maintenance Supervisor
DESCRIPTION:
This use case provides typical steps for checking out equipment.
PRE-CONDITION:
Maintenance staff member is login to any one of the two warehouse terminals.
TRIGGER:
User submitted a Check-Out Equipment request.
TYPICAL COURSE of EVENTS
;
Actor Action
Step 1. User enters in equipment desired.
System Response
Step 2. System verifies user’s employment status (not terminated) and skill level. Skill level must be equal to or
greater than equipment classification.
Step 3. System checks availability of equipment (not all checked out).
Step 4. System updates the Checked Out List.
Step 5. System deducts any supplies from inventory.
Step 6. System prints a Check Out Receipt.
Step 7. User takes receipt to Equipment Depot counter.
Step 8. Equipment Depot staff may check Lost and Damaged Equipment Report against employee.
Step 9. Equipment Depot honors check out request.
ALTERNATE COURSES:
Equipment Depot staff already automatically notified of the Maintenance Staff having too many checked out equipment, or history of damaged, lost equipment by Exception Problem Report.
Equipment Depot refuses to honor check out with out supervisor approval.
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
•
•
Maintenance Supervisors setup up constraints for Exception Problem Reports (define x).
Safety committee determines the appropriate skill level for using equipment.
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
OPEN ISSUES:
25HNS-32099 7/15/2004
Possibly have system refuse to submit a Check Out Receipt based on Exception Problem Report.
Better Software Conference 2004
Avoiding Over Analysis
Required Depth of
Understanding
When documenting requirements, avoid trying to understand too
many details. This condition is called analysis paralysis. To address
the problem of analysis paralysis, one could use a graphical chart
with the vertical axis measuring the depth of understanding, and the
horizontal axis listing the disciplines or subsystems that need to be
understood (Maier). Some disciplines need less depth of
understanding. In some cases it will be obvious which disciplines
require less depth.
A
B
C
D
E
Disciplines and Subsystems
26HNS-32099 7/15/2004
Better Software Conference 2004
Prioritizing Requirements
• Some requirements provided are within the solution scope, but it
is unclear whether or not they are mandatory. Users have a
tendency to label too many requirements as mandatory. A quick
test to determine if a list of requirements is mandatory or not is
attempting to rank them. You should not be able to rank any
requirement that you absolutely must have (Azani).
• Regarding priority, assign the difficult requirements highest
priority. In risk management terms, if the hard parts of
construction are left for last, the risk level and uncertainty will
remain high. Justification for the system may begin to erode over
time. In the private sector such a system not yet demonstrating
capability would be considered high-risk capital venture. In
government acquisition, political challenges will occur (Maier).
27HNS-32099 7/15/2004
Better Software Conference 2004
Knowing Requirements Conflict
• According to a Georgia State University study (Robinson, 2003),
two basic forces give rise to requirements conflict, technical and
social. The authors recommend an emerging concept of
Requirements Interaction Management (RIM) to address these
conflicts.
• Technical difficulties that lead to requirements conflict:
– Voluminous requirements
– Changing requirements and analysts
– Complex requirements
• Social difficulties that lead to requirements conflict:
– Conflicting stakeholder requirements
– Changing and unidentified stakeholders
– Changing expectations
28HNS-32099 7/15/2004
Better Software Conference 2004
Defining Open Systems
• The biology concepts of open and closed systems describe closed
systems as self-reliant, and open systems as having to exchange
with its environment for survival (Frank, 2002). From an
engineering perspective, closed systems are very proprietary,
whereas open systems are non-proprietary
• To reduce the risk of uncertainty of a system’s end purpose, select
options to build in and maintain. This will allow early decisions to
be changed or functionality extended. One such strategy for
software is use of open architectures (Maier). This could allow
tailoring future customer-expressed needs without major changes.
• Open systems architecture can be obtained using the following
design principles (Azani):
– Use a modular approach to architecture and design
– Acquire components instead of building
– Identify critical interfaces and use industry recognized
standards for these interfaces
– Verify that requirements permit the wider use of open
standards
29HNS-32099 7/15/2004
Better Software Conference 2004
Conclusion
• In the 1960s, IBM wrote the requirements for the 360 computer
system, a family of models. This family approach allowed the
system 360 to grow with owners and users by upgrading from a
smaller model to a larger, compatible model. As a matter of fact,
it didn’t use the virtual memory operating system that was being
introduced at the time. Soon, the virtual memory approach
dominated operating systems. Yet, the system 360 was widely
successful for many years to come.
• Today the requirement to have a computer system grow with the
company seems obvious, but in the early days of mainframes, it
was not so obvious. Hence, the need for requirements
analysis—to discover what is not so obvious.
30HNS-32099 7/15/2004
Better Software Conference 2004
References
• Azani, Cyrus. (n.d.). Open System Development Strategy. University
•
•
•
•
•
•
of Maryland. Unpublished.
Buede, Dennis. (2000). The Engineering Design of Systems: Models
and Methods. John Wiley and Sons: New York: NY
Fowler, M., and Scott, K. (1999). UML Distilled: A Brief Guide to the
Standard Object Modeling Language. 2nd Edition. Addison Wesley
Frank, Michael. (2002). The History of American Management
Thought: A Perspective and Analysis. The Development of
Management Theory and Practice in the United States. Pearson
Custom Publishing: Boston, MA
Maier, M., and Rechtin, E. (2002). The Art of Systems Architecting.
2nd Edition. CRC Press: Boca Raton, Florida.
Robinson, W., Pawlowski, S., Vecheslav, V. (2003, June).
Requirements Interaction Management. Georgia State University.
ACM Computing Surveys. Vol. 35, No. 2, pp. 132-190. Retrieved on
May 26, 2004, from database ACM Digital Library.
Whitten, J., Bentley, L., Dittman, K. (2004). Systems Analysis and
Design Methods. 6th Edition. McGraw Hill/Irwin: New York, NY.
31HNS-32099 7/15/2004
Better Software Conference 2004
Discovering Requirements
Discovering the True Software Requirements
Paul DeSantis
Better Software Conference & EXPO 2004
1
Discovering Requirements
2
Table of Contents
Abstract ............................................................................................................................... 3
1. Introduction................................................................................................................. 4
2. Background Information............................................................................................. 4
2.1.
What makes requirements important?..................................................................... 4
2.2.
Overview of Systems Analysis ............................................................................... 5
3. Phase One Scope Definition........................................................................................ 6
4. Phase Two Problem Analysis...................................................................................... 7
5. Phase Three Requirements Analysis........................................................................... 8
5.1.
Identifying the Stakeholders.................................................................................... 8
5.2.
Understanding the Stakeholders and Their Perspectives ...................................... 10
5.3.
Discovering Requirements .................................................................................... 11
5.4.
Documenting and Expressing Requirements ........................................................ 16
5.4.1. Natural Language Sentence................................................................................... 16
5.4.2. Use-case Analysis ................................................................................................. 17
6. Avoiding Over Analysis............................................................................................ 21
7. Prioritizing Requirements ......................................................................................... 22
8. Knowing Requirements Conflict............................................................................... 22
9. Defining Open Systems............................................................................................. 22
10.
Conclusion............................................................................................................. 23
11.
References ............................................................................................................. 24
Discovering Requirements
3
Abstract
In May 2004, the Federal Communications Commission (FCC) proposed new
requirements for an emerging technology, Broadband over Power Lines (BPL).
Broadband over Power Lines is the ability of running high-speed broadband
communications for Internet access over existing power lines. One would simply
connect up to their electrical outlet, instead of a telephone line, wireless connection or
DSL. Unfortunately, experiments have shown that BPL provides radio interference with
electrostatic discharge.
The FCC, in an attempt to address the radio inference of BPL, proposed a requirement,
which is: Make it easier to track down who is responsible for interference and a shutdown feature to deactivate units found to cause harmful interference (Sumner, p. 9,
2004).
Notice that the FCC proposal does not describe the technical details in how to track down
interference and the shutdown feature. It doesn’t include a cost involved, a possible
solution or technique, and it is not directed to a particular utility company. Just a formal
statement describing what the government wants and needs from BPL.
This paper will discuss requirements analysis, which defines what the users need and
want from a new system. Also, it will identify the users, their perspectives, and how to
collect and analyze their requirements.
Discovering Requirements
4
1. Introduction
This paper discusses an academic approach to fact-finding techniques for
requirements discovery. It starts with a brief discussion of the first phases of systems
analysis, scope definition and problem analysis. Then comprehensively explains
requirements analysis by offering techniques in problem discovery and analysis,
requirements discovery, documenting and analyzing requirements, requirements
management, sampling of existing documentation, research, environment observation,
questionnaires, interviews, prototyping, and joint requirements planning.
To provide a complete understanding of systems analysis, this paper will explain
what questions are answered by the first several phases of systems analysis, and how to
create and use each phase’s set of deliverable components. These are:
•
•
•
•
•
Matrix of problems, opportunities, objectives and constraints
PIECES framework for problem identification
Cause and effect diagram
Problem statement matrix
Use-case glossary, diagrams and narratives.
Using this framework, one can study business problems and opportunities, then
transform the business and information requirements into specifications for information
systems. The final phases of logical design and decision analysis are also briefly
introduced.
System architectures have several building blocks with each stakeholder having a
different perspective, and wants and needs, regardless of the business drivers. This
framework will also discuss the different perspectives for each block, which will enable
the system analyst to customize requirements analysis for each stakeholder. This will
produce more effective requirements discovery and bridge any communications gap.
The presentation will conclude by listing open systems design principles.
This hybrid methodology can be used with any development strategy.
2. Background Information
2.1. What makes requirements important?
In the software engineering industry, knowing requirements is important because
mistakes made in the front end of the development life cycle, which includes
requirements analysis, can have substantially negative impacts on the systems design’s
total cost, time schedule, and customer satisfaction (all features included). Still, this
reason may not help explain how requirements are important.
Discovering Requirements
5
Instead of listing the many different definitions of requirements and requirements
types, this paper will simply define requirements as the needs of the stakeholders. One
could also view requirements as solving problems. It is the stakeholders’ needs that
become the originating requirements—the business requirements. These originating
requirements are major inputs for almost every design function (Buede). Case in point:
Derived requirements and developed architectures come from originating requirements.
If the source is wrong, what follows will also be wrong. This is why requirement are
important; they influence the entire development life cycle.
The process of discovering and expressing business requirements for a new
system is called requirements analysis. The profession performing the work is known as
systems analysts. This paper will explain requirements analysis from a systems analysis
perspective. Systems analysis is a problem-solving technique for business problems. It
decomposes a system into components for the purpose of studying how well these
components work together to accomplish their objective. System analysis occurs before
system design, which focuses on the technical aspects of the system (Whitten, 2004).
2.2. Overview of Systems Analysis
An overview of system analysis in regards to its phases, objective of each phase,
tasks, and deliverables is as follows:
1. Scope Definition Phase
a. This phase answers the question, “Is it worth looking at this project?”
b. Deliverables: Brief Statement of Problem and Solution, and Problem
Statement Matrix
c. Tasks involved:
i. Identify baseline problems and opportunities
ii. Negotiate baseline scope
iii. Assess baseline project worthiness
iv. Develop baseline schedule and budget
v. Communicate the project plan
2. Problem Analysis Phase
a. This phase answers the question, “Are the problems really worth solving?”
b. Deliverables: Problems, Opportunities, Objectives and Constraints Matrix,
a Cause and Effect Diagram, and PIECES worksheet
c. Tasks involved:
i. Understand the problem domain
ii. Analyze problems and opportunities
iii. Analyze business processes
iv. Establish system improvement objectives
3. Requirements Analysis Phase
a. This phase answers the question, “What do the users need and want from a
new system?”
b. Deliverables: Use-cases glossary, diagrams, and narratives
Discovering Requirements
6
c. Tasks involved:
i. Identify and express system requirements
ii. Prioritize systems requirements
4. Logical Design Phase
a. Performs Systems modeling or prototyping
b. Deliverables: A prototype of solution (product), a Unified Modeling
Language (UML) model, a data model, or a process model
c. Tasks involved:
i. Structure functional requirements
ii. Prototype functional requirements
iii. Validate functional requirements
iv. Define acceptance test cases
5. Decision Analysis Phase
a. Identify options, analyze options, then sell best solution
b. Deliverables: Candidate Systems Matrix, Feasibility Analysis Matrix, and
System Proposal (written report)
c. Tasks involved:
i. Identify candidate solutions
ii. Analyze candidate solutions
iii. Compare candidate solutions
iv. Recommend a system solution
3. Phase One Scope Definition
Of all the systems analysis phases, this one is the shortest, just days to complete.
Executive management makes the scope decision. The scope definition phase assesses
the project worthiness by answering, “Is it worth looking at this project?” To help assess,
a problem statement matrix is used for listing statements about the problem, and
assigning dispositions to each one. Other operational and technical feasibility techniques
may be used.
Sample Problem Statement Matrix
Brief
Statements of
Problem,
Opportunity,
or Directive
List of
statements
identifying
the problem,
opportunity,
or directive
Urgency
Visibility
Annual
Benefits
Priority or
Rank
Proposed
Solution
Time Frame
to solve
problem,
rating scale
What degree
would the
solution be
visible to
customers,
rating scale
Dollar
estimate (best
guess) of
savings or
increase in
revenue
Rating scale
At this phase,
possible
solutions
expressed in
simple terms
Discovering Requirements
7
4. Phase Two Problem Analysis
Two artifacts completed in the problem analysis phase, and later used in the
requirements analysis phase, are the Problems, Opportunities, Objectives, and Constraints
Matrix and the Performance, Information, Economics, Control, Efficiency and Service
(PIECES) framework.
•
Problems, Opportunities, Objectives, and Constraints Matrix
This matrix will help establish system improvement objectives that will later be
used as requirements. This matrix will establish the problem, the causes and
effects (symptoms) of the problem, solutions (the objective), and the constraints
(limitations on achieving the objectives). It is important not to identify a
symptom as a problem. The popular cause-and-effect diagram, also known as the
fishbone diagram and Ishikawa diagram, can be used in conjunction with this
matrix.
A word of caution for builder-architected systems: Often the solutions associated
with these systems are looking for a problem, which makes them vulnerable to
working on the wrong problem (Maier, p. 42).
Sample Problems, Opportunities, Objectives, and Constraints Matrix
Cause-and-Effect Analysis
Problem or
Causes and Effects
Opportunity
Problem statement
Possible causes of
the problem, or the
symptoms
•
Systems Improvement Objectives
System Objective
System Constraints
What you expect to
achieve
Something that will
reduce your
flexibility in
defining an
improvement
PIECES
Professor and author Dr. James Wetherbe developed a framework for classifying
problems called PIECES. Each category has problems that need to be corrected or
improved. It is these categories that help with brainstorming. Other categories may
be added for specific system needs. Some problems may show up in multiple
categories. Below is a sample PIECES Problem –Solving Framework and Checklist
(Whitten, p. 94).
Discovering Requirements
Sample PIECES
Performance
A. Throughput
B. Response
Information (and data)
A. Outputs
B. Inputs
C. Stored Data
Economics
A. Costs
B. Profits
Control (and security)
A. Too little security or control
B. Too much security or control
Efficiency
A. People, machines, or computers
waste time
B. People, machines, or computers
waste materials and supplies
C. Effort required for tasks is
excessive
D. Material required for tasks is
excessive
Service
A. System produces inaccurate results
B. System produces inconsistent
results
C. System is not easy to use
D. System is incompatible with other
systems
5. Phase Three Requirements Analysis
5.1. Identifying the Stakeholders
One of the primary roles of a Systems Analysis in the development of systems is to
collect the needs from the stakeholders, and bridge communications gap between
nontechnical and technical stakeholders. Who are these stakeholders and what role do
they perform?
•
•
System Owners
These stakeholders are usually middle to executive level managers who are
concerned about cost and value, which would include:
o Increased business profit
o Reduced business cost
o Improved customer relation
o Increased efficiency
o Better compliance with regulation
Systems Users
These stakeholders are concerned about getting the job done using the
functionality of the system, along with its ease of use and learning. There are
many types of system users, categorized as either internal or external.
8
Discovering Requirements
9
o Internal System Users
§ Clerical and Service Workers
Workers that perform the day-to-day transaction processing
§ Technical and Professional Staff
Workers that perform highly skilled and specialized work
§ Supervisors, Middle and Executive Managers
Decision makers focusing on day-to-day problem solving
o External System Users
Also known as remote or mobile users. The Internet has extended
information system boundaries, which adds external users such as:
§ Customers
The purchasers using the system to directly execute a sales
transaction
§ Suppliers
The providers of supplies and raw material using the
system to check supply needs and fulfill orders
§ Partners
Another company with a business contract to provide
services.
§ Employees
Employees of the company owning the system, who are on
travel or telecommunicating
•
System Designers
Technical specialists who translate the business requirements into technical
solutions, by designing the various system components. Technical specialties are:
o Database administrators
o Network architects
o Web architects
o Graphics artists
o Security experts
o Other specialists (experts in the application of a given technology)
•
System Builders
Technical specialists who construct the system according to the system designer’s
specifications.
o Applications programmers
o Systems programmers
o Database programmers
o Network administrators
o Security administrators
o Webmasters
o Software integrators
Discovering Requirements
10
5.2. Understanding the Stakeholders and Their Perspectives
Authors Whitten, Bentley and Dittman developed a Framework for Information
Systems Architecture that does a wonderful job of representing stakeholders and their
different perspectives. Their framework consists of building blocks representing a
system and its different views. This section uses the building blocks of business
knowledge, business processes, and business communications to describe each
stakeholder’s view of what they want and need from a system (Whitten).
Knowledge Building Blocks
•
•
•
•
System owners’ view of knowledge is to identify business entities and rules, and
is interested in the information that adds new business knowledge about these
entities and rules. Example of entities: Customer Mr. Smith has placed X number
of orders. In this example, the business entities are customer and orders.
Example of rules: Only customers can place orders. Owners aren’t interested in
details (attributes) of entities or rules.
System users’ view of knowledge will provide data requirements, which are an
extension of business entities and rules. Users are concerned about the details
(attributes) of entities and rules. Example: The entity of order could have the
attributes of rush shipment or normal shipment. Users may also expand the list of
entities and rules.
System designers’ view of knowledge will translate the system users’ business
data requirements into a database design. Their concern is with database
technology and view of knowledge consists of data structures, fields, indexes, etc.
System builders’ view of knowledge will construct the actual database structure
using tools and techniques (i.e., SQL), based on the designer’s ideas.
Process Building Blocks
•
•
•
•
System owners view processes in the form of business functions (sales, service,
manufacturing, shipping, receiving, and accounting). These business functions
can be described as many events and responses. Example:
Event - Customer submits order.
Response - Shipping department ships order.
System users view processes as the work required to carry out the business
function’s response to an event, in accordance to policy.
System designers view processes as determining which processes (work) can be
automated, and how best to automate them using available technology.
Systems builders view processes from the perspective of programming languages
in order to build the application program.
Discovering Requirements
11
Communication Building Blocks
•
•
•
•
System owners view communication as the business units of employees,
customers, and external businesses that interface to the new system. Also, where
are they located? In addition, what type of other systems will interface?
System users view communication as it is concerned with the basic interaction
with the system. The inputs and expected outputs, and the details of each are
important. Note: Users will want the look and feel of their favorite PC tools (i.e.,
Excel).
System designers view communication as it is concerned with the interface
specifications and user dialogue (movement among windows), which can be
difficult to design. Graphical design specialist and human-computer interface
specialist may help with design.
System builders view communication to construct system-to-system and systemto-user interfaces using middleware and graphical user interface technology.
5.3. Discovering Requirements
Now that the stakeholders are known, and their views and concerns understood, the
system analyst next identifies their needs. Requirements discovery has multiple
techniques, each with advantages and disadvantages. This paper will discuss seven
common techniques. An analyst ought to apply several techniques to a single project,
selecting the most suitable ones given the situation.
1. Sample Existing Documentation, Forms and Files
This technique will collect various types of existing documents, forms, and
reports. Perhaps too many to study. In this case, a sampling technique of some
sort should be utilized. Some of the information that should be retrieved is:
• The Problems, Opportunities, Objectives, and Constraints Matrix and
PIECES artifacts
• Organizational charts to identify stakeholders that will be a source of
information
• Documents describing business functions, policies, and mission statements
for both individual departments and the company as a whole
• Documents containing design information about predecessor system,
operator manual and work instructions
2. Literature Research
This technique involves having the system analyst research the problem being
solved for background information, and understanding the problem domain. The
analyst would research trade journals, periodicals, industry books. Also, because
not all problems are unique, it may already be solved. The analyst may want to
visit a physical site that already solved the problem, assuming the company is
willing to share information.
Discovering Requirements
12
3. Observation of the Work Environment
This technique has the analyst performing a site visit that allows them to observe
the work environment. Simply stated, watching the system in action. This is one
of the more effective data-collection techniques. The system analyst will observe
the people and activities to learn their needs, and will also verify information
collected from other techniques.
There are more disadvantages than advantages with site visits, but with proper
preparation and determining how to capture information beforehand, site visits
can be useful.
Etiquette takes precedence with site visits, requiring permission from appropriate
managers, not interrupting productivity, keeping a low profile, and knowing that
some people will behave differently when watched. It is best to single out who
would be observed, including where, what, when, why and how. When done with
each observation, review notes with the person or manager to confirm if correct.
4. Questionnaires
When dealing with a large audience, this technique is efficient and effective. Like
studying existing documentation, it may require a good sampling technique if the
volume is too high. Although this technique is criticized for producing unreliable
and not useful information, Purdue University Professor Jeffrey Whitten believes
many of the criticisms are due to inappropriate or ineffective use of
questionnaires. He offers the following advice and guidelines when developing a
questionnaire:
•
•
•
•
•
Determine what facts, opinions and from whom data must be collected.
Based on the facts and opinions sought, develop the appropriate question
format.
Write the questions, and then inspect them for errors and possible
misinterpretation.
Test the questions on a small group first. Adjust accordingly.
Duplicate and distribute questionnaire.
There are two basic question formats. These are described below along with their
characteristics.
•
Free-format Questionnaire
These are designed to allow users to exercise more freedom or latitude in
their answers. Example: What reports do you currently receive and how
are they used?
Use simple sentences that do not leave room for different interpretations
among respondents. Also, questions asked should be answerable with
three sentences or less.
Discovering Requirements
•
13
Fixed-format Questionnaire
These are more rigid, requiring the respondent to select from a predetermined list of answers. Fixed format questions types are:
o Multiple choices. These can also allow for free-format responses
when none of the answers apply. Example: What is your job title?
Engineer, Scientist, Other (please specify)
o Rating. These are used to gather opinions. Example: Do you like
how the web feature executes? Strongly Agree, Agree, Disagree.
To prevent any build-in biases, an equal number of positive and
negative ratings should be used.
o Ranking. These allow respondents to rank a set of answers in order
of preference. Example: Rank the following web feature in order
of importance: _ mandatory, _ useful, _ not useful.
5. Interviews
This technique uses personal interviews between the analyst and the system users
(not the system owners). This approach has more advantages than disadvantages
and is looked upon as the most common and most important technique for
collecting requirements. Possibly because it fulfills the many goals of finding,
verifying, and clarifying facts, identifying requirements, solicit ideas and
opinions, and gets users personally involved, which is preferred by users. Before
conducting interviews, collect as many facts as possible.
Like questionnaires, there are different types of interviews and different question
formats. These are:
•
•
Unstructured interview: Analyst asks general questions and let
interviewees direct conversations. This type of interview generally
doesn’t work well due to conversations getting off track. Questions are
usually open-ended allowing the interviewee to respond in any way.
Structured interview: Analyst ask specific questions to solicit specific
information, then follows up with another question for further
clarification, if necessary. Questions usually are closed-end that restrict
answers to specific choices, or short-direct response.
Conducting the interviews:
Step 1: Select the interviewees, once again specifically the end users and not
the owners. Make an appointment with the users after obtaining their
management’s approval for participation, then attempt to get to know the
users (i.e., job description, strengths, weaknesses).
Step 2: Prepare an interview guide, see example below, which will list
proposed questions in order and any anticipated follow up questions. When
writing the questions, use the same advice listed in the questionnaire section
Discovering Requirements
14
of this paper. In addition, questions should be investigative. Do not provide
opinions or criticize. It is okay to deviate from the list of proposed questions
in order to probe for more information. It is expected for the analyst to adapt
to the interview.
Sample Interview Guide:
Meeting Subject:
Date:
Time:
Place:
Interviewees:
Time Allocated
Interviewer Question or
Objective
5 minutes
Opening Statements
• Everybody introduces
themselves
• State purpose of
meeting
2 minutes
Question 1
Will only your department
be logging into the system?
Follow up
2 minutes
Question 2
Will the system need to
verify your login for
security clearances?
Follow up
What are the clearance
levels?
5 minutes
Conclusion
• Thank everybody again
for attending
• Promise to follow up
General Comments and Notes:
Interviewee Response
Step 3. Conducting the interview.
The interview consists of three parts: opening, body and closing. The system
analyst can easily open the meeting by stating the purpose and objective of the
meeting by making a statement like, “I want to get consensus on everything
the system needs to do and who will be using which functionality.”
The body of the interview will consist of the questions. It is here that the
analyst must listen carefully to each response including non-verbal responses
Discovering Requirements
15
as in body language, keep the interview on track, and take many notes. There
are three forms of listening (Lewicki, 2004): Passive (receiving message while
providing no feedback), acknowledgement (nod head, interject responses like
“I see”), and active listening (restate or paraphrase the sender’s message).
Interviewers should use acknowledgement or active listening. Note: Beware
of those users who are providing requirements that are outside the scope of the
solution approved by the system owners.
The closing should have the analyst answering any questions from the
interviewees, thanking them for their attendance, and promising to follow up
with the documented requirements.
Some helpful rules for the interviewer:
•
•
•
•
Do listen carefully
Do be courteous
Do ask more questions to probe or seek clarification
Do take notes
•
•
•
•
Don’t assume anything
Don’t continue an interview unnecessarily
Don’t talk instead of listening
Don’t criticize or evaluate
6. Discovery Prototyping
This technique involves building a prototype for the purpose of identifying
requirements by having users test the working model and provide feedback. This
is called discovery prototyping, which is different than prototyping in the
development strategy of rapid application development (RAD). This paper
suggests discovery prototyping would be too difficult for projects to implement if
using a development strategy other than RAD (i.e., modeling), even though it has
many advantages.
7. Joint Requirements Planning (JRP)
JRPs are group work sessions, and are a formal alternative to numerous
interviews. JRPs are becoming common, especially when required to reach a
consensus on requirements. Unlike interviews, JRPs last several days and have
the system owners present. If executed correctly, JRPs can resolve conflicting
information and requirements, and obtain a consensus among users and managers.
The list below shows the participants and their roles.
•
Sponsor: This person has authority to make decisions about the project.
Sponsors determine who should attend the JRP and play a visible role
throughout the session. The system analyst works with the sponsor to
determine the scope of the project addressed through the JRP.
Discovering Requirements
•
•
•
•
16
Facilitator: This person conducts the session, leads discussions,
encourages participation among all attendees, resolves conflicts, and helps
the JRP fulfill its goals and objectives. They may establish ground rules
for the JRP.
System users and managers: They ensure that their needs to be successful
in their day-to-day work tasks are being addressed by the system, and will
provide the most input.
Scribe: This person or persons keep records of the session for immediate
publication and distribution afterwards. This will keep the requirements
analysis momentum. Because records will include technical
documentations, such as models, CASE tools are required along with the
appropriate expertise. Usually, a systems analyst acts as the scribe.
IT staff: These attendees’ role is passive, being called upon to answer
technical questions. They will take notes and help the scribe in
developing the technical documentation.
JRPs should be conducted offsite in order for attendees to concentrate on the
activities and prevent interruptions. A formal conference room is required
with visual aids (overhead projector, whiteboard, and flipcharts). The scribes
require computers running CASE and office tools. Physical layout grouping
the attendees per function is recommended.
The JRP agenda will include brainstorming, interviewing, or any other
technique, to generate as many requirements possible.
The facilitator and scribes are the most important people to make a JRP
session a success.
5.4. Documenting and Expressing Requirements
Once the systems analyst is complete in identifying all requirements, the analyst must
document or express the requirements, and analyze them in the process. Expressing the
requirements can be done using natural language sentence or use-case analysis.
5.4.1. Natural Language Sentence
Most projects will write business requirements using simple statements (sentences). The
statements structure shall be broken down into the following components:
•
•
Subject (The system of interest)
Verb phrase usually starting with the word shall, but others are applicable.
o Shall indicates limiting nature of the requirement
o Will indicates a fact
o Should indicates a goal
Discovering Requirements
•
•
•
17
Object that describes the input, output, etc.
Minimal acceptable threshold with units (optional)
Conditions that would make the statement true (optional)
Example of a requirement statement (also referred to as requirement text):
•
The system shall prompt the user with a login screen upon touch of the
keyboard.
Use the following rules when writing requirements (Buede):
•
•
•
•
•
•
Do not use compound predicate. This will cause problems with tracing in
requirements management. Example: The system shall fit.., weigh.., cost…
Do not use negative predicates, which will describe what the system is not to
do. Example: The system shall not…
Do not use and/or, which will provide the designers with a choice. Also, do
not use colloquialism.
Do not start a requirement with a conditional statement. Example: If the input
is…the system shall... Instead, conditions that make the requirement true
should be placed at the end of the sentence.
Do not use ambiguous verbs such as maximize or minimize.
Do not use ambiguous adjectives. Most common ones are: adaptable,
adequate, easy, flexible, rapid, robust, sufficient, supportable, and userfriendly.
5.4.2. Use-case Analysis
In software engineering, requirements discovered are also expressed using usecase analysis. Use-case analysis is a modeling process part of the UML standard. This
technique will produce a use-case glossary, use-case model diagram, and use-case
narrative artifacts. This paper will briefly introduce the technique. It is recommended for
the reader to consult formal publications on UML for proper teachings of its semantics
and notations.
Note: Modeling requirements is not effective for expressing performance (Maier), which
remember, is a system category of the PIECES framework.
Use-case Diagrams
This diagram graphically depicts the system and its interactions within the given
environment by using a collection of modeling elements. These are use-cases, actors and
their relationships. Element descriptions are as follows (Fowler).
Discovering Requirements
•
•
•
18
Use-cases: The sequence of events (transactions) a system performs to
yield an observable result. Each use-case can be viewed as a function.
Actors: Actors are users of the system, either for input or output. These
users exist outside the system. Users can be a human being, or another
computer. There are four types of actors:
o Primary: This user is the one primarily benefiting from the usecase execution by receiving an output.
o Primary System Actor: This user directly interfaces with the
system to initiate the transaction.
o External Server Actor: This user responds to a request from a usecase.
o External Receiver Actor: This user is not the primary actor but also
receives something of value from a use-case output.
Relationships: A use-case has relationships between an actor and other
use-cases. The three types of relationships are:
o Include: Provides common functionality
o Generalization: Almost common steps among use-cases
o Extend: An alternative or exception to normal behavior
Example use-case diagram:
Order Subsystem
Maintenance Staff
<<includes>>
Check Out
Equipment Available Status
System
Check Out Receipt
Check In
Equipment Depot
Discovering Requirements
19
Use-case glossary:
This tabular list has all the identified use-case names, a one paragraph description
for each case, and the participating actors and roles.
Example use-case glossary:
Use-Case Name
Check Out
Check Out Receipt
Check In
Equipment Availability
Status
Use-Case Description
Participating Actors and
Roles
This use-case describes the
Maintenance Staff
event of a maintenance staff (primary)
member requesting use of
Equipment Availability
equipment, by filling a form Status (external server)
containing type of
equipment, reason, job
number, etc.
This use-case describes the
System (primary)
event of the system printing Maintenance Staff (external
a completed Check Out
receiver)
form.
Equipment Depot (external
receiver)
This use-case describes the
Equipment Depot Staff
event of equipment depot
(primary)
staff receiving checked out
equipment from
maintenance staff, putting
equipment physically back
into depot, and then
updating system.
This use-case describes the
System (primary)
event of notifying the check Check Out (external
out use-case of equipment
receiver)
already checked out, or on
order.
Use-Case Narrative
This artifact formally documents each use-case by expanding them into a step-bystep narrative (description). One narrative per use-case. In the sample template below,
many fields make up the narrative. Some of the fields require explanation.
•
•
Precondition: This is a constraint on the state of the system before the usecase can be executed.
Trigger: This is the event that initiated the execution of the use-case.
Discovering Requirements
•
•
•
•
•
•
•
20
Typical Course of Events: This is the normal sequence of activities
performed by both actor and the system to satisfy the objective of the usecase.
Alternative Courses: This documents the behavior of the use-case in an
exception or variation to the typical course of events.
Conclusion: This specifies when the use-case successfully ends.
Post Condition: This is a constraint on the state of the system after the usecase has been successfully executed.
Business Rules: These specify policies and procedures of the business for
the system to abide by.
Assumptions: Any assumptions that were made by the author when
writing the narrative.
Open Issues: Any issues that need to be resolved prior to finalizing usecase.
Example use-case narrative:
USE-CASE NAME:
USE-CASE ID:
PRIORITY:
SOURCE:
PRIMARY BUSINESS
ACTOR:
OTHER
PARTICIPATING
ACTORS:
OTHER INTERESTED
STAKEHOLDERS:
DESCRIPTION:
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE of
EVENTS
Check-Out Equipment
USE-CASE TYPE
Business Requirements:
þ
High
Cause & Effect Analysis and Personal
Interviews
Maintenance Staff
•
•
Equipment Depot
System
•
Maintenance Supervisor
This use-case provides typical steps for checking out equipment.
Maintenance staff member is login to any one of the two warehouse terminals.
User submitted a Check-Out Equipment request.
Actor Action
System Response
Step 1. User enters in equipment
desired.
Step 2. System verifies user’s employment
status (not terminated) and skill level. Skill
level must be equal to or greater than
equipment classification.
Step 3. System checks availability of
equipment (not all checked out).
Step 4. System updates the Checked Out
List.
Step 5. System deducts any supplies from
inventory.
Step 6. System prints a Check Out Receipt.
Step 7. User takes receipt to
Equipment Depot counter.
Step 8. Equipment Depot staff may check
Lost and Damaged Equipment Report
against employee.
Discovering Requirements
21
Step 9. Equipment Depot honors check out
request.
Equipment Depot staff already automatically notified of the Maintenance Staff
having too many checked out equipment, or history of damaged, lost equipment
by Exception Problem Report.
Equipment Depot refuses to honor check out with out supervisor approval.
ALTERNATE COURSES:
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
•
•
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
OPEN ISSUES:
Maintenance Supervisors setup up constraints for Exception Problem
Reports (define x).
Safety committee determines the appropriate skill level for using equipment.
Possibly have system refuse to submit a Check Out Receipt based on Exception
Problem Report.
6. Avoiding Over Analysis
Required Depth of
Understanding
When discovering and documenting requirements, avoid trying to understand too
many details. The condition of a systems analysis performing excessive modeling that
slows progress is called analysis paralysis. To address the problem of analysis paralysis,
one could use the same solution proposed for understanding system architectures in a
1987 lecture by Bob Spinrad at the University of California. This is a graphical answer
shown below (Maier, p. 8). A chart with the vertical axis measuring the depth of
understanding, and the horizontal axis listing the disciplines or subsystems that needs to
be understood. Notice some disciplines need less depth of understanding. How does an
analyst know what details of what disciplines are critical? In some cases it will be
obvious; in other cases experience will be required.
A
B
C
D
Disciplines and Subsystems
E
Discovering Requirements
22
7. Prioritizing Requirements
Some requirements provided are within the solution scope but unclear whether it is
mandatory. Users have a tendency to label too many requirements as mandatory. A
quick test to determine if a list of requirements is mandatory or not is attempting to rank
them. You should not be able to rank any requirement that you absolutely must have
(Azani).
Regarding priority, assign the difficult requirements highest priority. In risk
management terms, if the hard parts of construction are left for last, the risk level and
uncertainty will remain high. Justification for the system may begin to erode over time.
In the private sector such a system not yet demonstrating capability would be considered
high-risk capital venture. In government acquisition, political challenges will occur
(Maier, p. 44).
8. Knowing Requirements Conflict
According to a Georgia State University study (Robinson, 2003), two basic forces
give rise to requirements conflict, technical and social. The authors recommend an
emerging concept of Requirements Interaction Management (RIM) to address these
conflicts. This paper only desires to show what causes conflict, and will not discuss
RIM. Much work is needed to evolve RIM into a mature discipline and RIM approaches
must be unified to become widely accepted.
•
•
Technical difficulties that lead to requirements conflict:
– Voluminous requirements
– Changing requirements and analysts
– Complex requirements
Social difficulties that lead to requirements conflict:
– Conflicting stakeholder requirements
– Changing and unidentified stakeholders
– Changing expectations
9. Defining Open Systems
The concepts of open and closed systems were developed by the biologist Ludwig
Von Bertalanfly (Frank, 2002). These biology system theories were later applied to
organizational management and engineering. Closed systems are self-reliant, and open
systems must exchange with its environment for survival. From an engineering
perspective, closed systems are very proprietary, whereas open systems are nonproprietary
To reduce the risk of uncertainty of a system’s end purpose, select options to build in and
maintain. This will allow early decisions to be changed or modified later. One such
Discovering Requirements
23
strategy for software is use of open architectures (Maier, p43). This could allow tailoring
future customer-expressed needs without major changes.
Open systems architecture can be obtained using the following design principles (Azani):
•
•
•
•
Use a modular approach to architecture and design
Acquire components, instead of building
Identify critical interfaces, and use industry recognized standards for these
interfaces
Verify all requirements permit the wider use of open standards
10. Conclusion
In his book, Software Development: Building Reliable Systems, author Marc
Hamilton (1999) published the ten commandments of successful software
development. The first two are, “thou shalt start development with software
requirements” and, “thou shalt honor thy users and communicate with them often”.
This paper agrees that successful software development does start with and include
the users and their requirements. After all, it is the users who will be using the
system every day for several years, or more.
When analyzing a system, the analyst is contributing to customer satisfaction
because the delivered system would be built exactly how the originating requirement
stated. This customer satisfaction comes from identifying all the people who have
valid inputs, understanding their needs from their perspective, asking the right
questions, listening to all responses, researching the correct documents, and then
expressing the information collected in a simple, unambiguous manner, while sorting
unnecessary requirements. Case in point: In the 1960s, IBM wrote the requirements
for the 360 computer system, a family of models. This family approach allowed the
system 360 to grow with owners and users by upgrading from a smaller model to a
larger, compatible model. As a matter of fact, it didn’t use the virtual memory
operating system that was being introduced at the time. Soon, the virtual memory
approach dominated operating systems. Yet, the system 360 was widely successful
for many years to come. So successful it drove General Electric out of the computer
business. The 360 was not necessarily the best technological computer, but a
computer that satisfied customer needs and wants, which was to have a computer
system to grow with the company.
Today the requirement in this case seems simple and obvious, but in the early
days of mainframes, it wasn’t so obvious. Hence, the need for requirements
analysis—to discover what isn’t so obvious.
Discovering Requirements
24
11. References
Azani, Cyrus. (n.d.). Open System Development Strategy. University of Maryland
University College. Unpublished.
Buede, Dennis. (2000). The Engineering Design of Systems: Models and Methods. John
Wiley and Sons: New York: NY
Fowler, M., and Scott, K. (1999). UML Distilled: A Brief Guide to the Standard Object
Modeling Language. 2nd Edition. Addison Wesley:
Frank, Michael. (2002). The History of American Management Thought: A Perspective
and Analysis. The Development of Management Theory and Practice in the United
States. Pearson Custom Publishing: Boston, MA
Hamilton, Marc. (1999). Software Development: Building Reliable Systems. Prentice
Hall.
Lewicki, R., Saunders, D., Barry, B., Minton, J. (2004). Essentials of Negotiation. 3rd
Edition. Irwin McGrawHill: New York: New York
Maier, M., and Rechtin, E. (2002). The Art of Systems Architecting. 2nd Edition. CRC
Press: Boca Raton, Florida.
Robinson, W., Pawlowski, S., Vecheslav, V. (2003, June). Requirements Interaction
Management. Georgia State University. ACM Computing Surveys. Vol. 35, No. 2, pp.
132-190. Retrieved on May 26, 2004, from database ACM Digital Library.
Sumner, David. (2004, may). BPL: What Now? QST Amateur Radio Journal. American
Radio Relay League. Volume 88, Number 5, P. 9.
Whitten, J., Bentley, L., Dittman, K. (2004). Systems Analysis and Design Methods. 6th
Edition. McGraw Hill/Irwin: New York, NY.