W15 September 29, 2004 3:00 PM D ISCOVERING THE T RUE S OFTWARE R - - PDF document

BIO PRESENTATION PAPER Better Software Conference & EXPO September 27-30, 2004 San Jose, CA USA

W15

September 29, 2004 3:00 PM

DISCOVERING THE TRUE SOFTWARE REQUIREMENTS

Paul Desantis Hughes Netw ork Systems

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.

Better Software Conference 2004 1HNS-32099 7/15/2004

Discovering the True Software Requirements

Paul DeSantis

Better Software Conference 2004 2HNS-32099 7/15/2004

Presentation Objectives

• 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

This paper discusses an academic approach to requirements analysis. Topics covered will be:

Better Software Conference 2004 3HNS-32099 7/15/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.

Better Software Conference 2004 4HNS-32099 7/15/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

• pportunities, Analyze business processes, Establish system

improvement objectives

Better Software Conference 2004 5HNS-32099 7/15/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

Better Software Conference 2004 6HNS-32099 7/15/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:

At this phase, possible solutions expressed in simple terms Rating scale Dollar estimate (best guess)

• f savings or

increase in revenue What degree would the solution be visible to customers, rating scale Time frame to solve problem, rating scale List of statements identifying the problem,

• pportunity, or

directive Proposed Solution Priority or Rank Annual Benefits Visibility Urgency Brief Statements

• f Problem,

Opportunity, or Directive

Better Software Conference 2004 7HNS-32099 7/15/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.

Something that will reduce your flexibility in defining an improvement What you expect to achieve Possible causes of the problem, or the symptoms Problem statement System Constraints System Objective Causes and Effects Problem or Opportunity Systems Improvement Objectives Cause-and-Effect Analysis 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

Economics

• A. Costs
• B. Profits

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

Information (and data)

• A. Outputs
• B. Inputs
• C. Stored Data

Control (and security)

• A. Too little security or control
• B. Too much security or control

Performance

• A. Throughput
• B. Response

Better Software Conference 2004 8HNS-32099 7/15/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

Better Software Conference 2004 9HNS-32099 7/15/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

Better Software Conference 2004 10HNS-32099 7/15/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.

Better Software Conference 2004 11HNS-32099 7/15/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.

Better Software Conference 2004 12HNS-32099 7/15/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

• utputs, 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-to- system and system-to-user interfaces using middleware and graphical user interface technology.

Better Software Conference 2004 13HNS-32099 7/15/2004

Discovering Requirements

• 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

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

Better Software Conference 2004 14HNS-32099 7/15/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
• ne 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.

Better Software Conference 2004 15HNS-32099 7/15/2004

Discovering Requirements

• 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.

4.

Questionnaires

Better Software Conference 2004 16HNS-32099 7/15/2004

Discovering Requirements

• 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.

• 5. Interviews

Better Software Conference 2004 17HNS-32099 7/15/2004

Discovering Requirements

• 6. Discovery Prototyping
• This technique involves building a prototype for the purpose
• f 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

• btain a consensus among users and managers.

Better Software Conference 2004 18HNS-32099 7/15/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).

Better Software Conference 2004 19HNS-32099 7/15/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.

Better Software Conference 2004 20HNS-32099 7/15/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, use- case 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):

Better Software Conference 2004 21HNS-32099 7/15/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 use- case output.

Better Software Conference 2004 22HNS-32099 7/15/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 use-

cases

• Extend: An alternative or exception to normal behavior

Order Subsystem Check In Equipment Depot Equipment Available Status System Check Out <<includes>> Check Out Receipt Maintenance Staff

Better Software Conference 2004 23HNS-32099 7/15/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.

System (primary) Check Out (external receiver) This use-case describes the event of notifying the check out use case of equipment already checked out or on order. Equipment Availability Status Equipment Depot Staff (primary) 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. Check In System (primary) Maintenance Staff (external receiver) Equipment Depot (external receiver) This use-case describes the event of the system printing a completed Check Out form. Check Out Receipt Maintenance Staff (primary) Equipment Availability Status (external server) This use-case describes the event of a maintenance staff member requesting use of equipment by filling out a form containing type

• f equipment, reason, job number, etc.

Check Out Participating Actors and Roles Use-Case Description Use-Case Name

Better Software Conference 2004 24HNS-32099 7/15/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 use- case. – Typical course of events: This is the normal sequence of activities performed by both actor and the system to satisfy the

• bjective of the use-case.

– Alternative courses: This documents the behavior of the use- case 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.

Better Software Conference 2004 25HNS-32099 7/15/2004

Documenting and Expressing Requirements

Possibly have system refuse to submit a Check Out Receipt based on Exception Problem Report. OPEN ISSUES: ASSUMPTIONS: IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS

• Maintenance Supervisors setup up constraints for Exception Problem Reports (define x).
• Safety committee determines the appropriate skill level for using equipment.

BUSINESS RULES POST-CONDITION: CONCLUSION: Equipment Depot refuses to honor check out with out supervisor approval. 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. ALTERNATE COURSES: Step 9. Equipment Depot honors check out request. Step 8. Equipment Depot staff may check Lost and Damaged Equipment Report against employee. Step 7. User takes receipt to Equipment Depot counter. Step 6. System prints a Check Out Receipt. Step 5. System deducts any supplies from inventory. Step 4. System updates the Checked Out List. Step 3. System checks availability of equipment (not all checked out). 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 1. User enters in equipment desired. System Response Actor Action TYPICAL COURSE of EVENTS User submitted a Check-Out Equipment request. TRIGGER: Maintenance staff member is login to any one of the two warehouse terminals. PRE-CONDITION: This use case provides typical steps for checking out equipment. DESCRIPTION:

• Maintenance Supervisor

OTHER INTERESTED STAKEHOLDERS:

• Equipment Depot
• System

OTHER PARTICIPATING ACTORS: Maintenance Staff PRIMARY BUSINESS ACTOR: Cause & Effect Analysis and Personal Interviews SOURCE: High PRIORITY: Business Requirements:

• USE CASE ID:

USE CASE TYPE Check-Out Equipment USE CASE NAME:

Better Software Conference 2004 26HNS-32099 7/15/2004

Avoiding Over Analysis

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 Required Depth of Understanding

Better Software Conference 2004 27HNS-32099 7/15/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).

Better Software Conference 2004 28HNS-32099 7/15/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

Better Software Conference 2004 29HNS-32099 7/15/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
• ptions 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

Better Software Conference 2004 30HNS-32099 7/15/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.

Better Software Conference 2004 31HNS-32099 7/15/2004

References

• Azani, Cyrus. (n.d.). Open System Development Strategy. University
• f 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.

Discovering Requirements 1

Discovering the True Software Requirements Paul DeSantis Better Software Conference & EXPO 2004

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 shut- down 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,

• r Directive

Urgency Visibility Annual Benefits Priority or Rank Proposed Solution List of statements identifying the problem,

• pportunity,
• r directive

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 Systems Improvement Objectives Problem or Opportunity Causes and Effects System Objective System Constraints Problem statement Possible causes of the problem, or the symptoms 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 8

Sample PIECES 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

• 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:

• Increased business profit
• Reduced business cost
• Improved customer relation
• Increased efficiency
• 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.

Discovering Requirements 9

• 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

• 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:

• Database administrators
• Network architects
• Web architects
• Graphics artists
• Security experts
• 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.

• Applications programmers
• Systems programmers
• Database programmers
• Network administrators
• Security administrators
• Webmasters
• 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

• f 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 system-

to-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,
• perator 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

• f 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 pre- determined list of answers. Fixed format questions types are:

• 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)

• 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.

• Ranking. These allow respondents to rank a set of answers in order
• f preference. Example: Rank the following web feature in order
• f 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

• pinions, 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

• f this paper. In addition, questions should be investigative. Do not provide
• pinions 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 Interviewee Response 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: 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

• f 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.
• Shall indicates limiting nature of the requirement
• Will indicates a fact
• 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 user- friendly. 5.4.2. 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, 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:
• 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 use-case output.

• Relationships: A use-case has relationships between an actor and other

use-cases. The three types of relationships are:

• Include: Provides common functionality
• Generalization: Almost common steps among use-cases
• Extend: An alternative or exception to normal behavior

Example use-case diagram:

Order Subsystem Check In Equipment Depot Equipment Available Status System Check Out <<includes>> Check Out Receipt Maintenance Staff

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 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 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

• ut use-case of equipment

already checked out, or on

• rder.

System (primary) Check Out (external receiver) Use-Case Narrative This artifact formally documents each use-case by expanding them into a step-by- step 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 use-

case 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 use- case.

• 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 use-

case 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 use-

case. Example use-case narrative:

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 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. 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: Possibly have system refuse to submit a Check Out Receipt based on Exception Problem Report.

• 6. Avoiding Over Analysis

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,

• ne 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

• bvious; in other cases experience will be required.

A B C D E Disciplines and Subsystems Required Depth of Understanding

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

• rganizational 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 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 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

• perating 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.