Software Engineering

CS-251
Lecture 14

Course Instructor: Sajid Khattak

1
 Analysis Concept and Principles
• Software requirements engineering is a process of discovery, refinement,
modeling, and specification.
• The system requirements and role allocated to software—initially
established by the system engineer—are refined in detail.
• Models of the required data, information and control flow, and operational
behavior are created. Alternative solutions are analyzed, and a complete
analysis model is created.

2
 Analysis Concept and Principles
• Donald Reifer describes the software requirement engineering process in the
following way:
• “Requirements engineering is the systematic use of proven principles,
techniques, languages, and tools for the cost-effective analysis, documentation,
and on-going evolution of user needs and the specification of the external
behavior of a system to satisfy those user needs.
• Notice that like all engineering disciplines, requirements engineering is not
conducted in an irregular, random or otherwise haphazard fashion, but instead is
the systematic use of proven approaches”
3
 Analysis Concept and Principles
• Both the software engineer and customer take an active role in software requirements engineering
—a set of activities that is often referred to as analysis.
• The customer attempts to reformulate a system-level description of data, function, and behavior
into concrete detail.
• The developer acts as interrogator, consultant, problem solver, and negotiator.
• Requirements analysis and specification may appear to be a relatively simple task, but appearances
are deceiving. Communication content is very high. Chances for misinterpretation or
misinformation abound. Ambiguity is probable.
• The dilemma that confronts a software engineer may best be understood by repeating the statement
of an anonymous (infamous?) customer: "I know you believe you understood what you think I
said, but I am not sure you realize that what you heard is not what I meant." 4
 Requirements Analysis
•Requirements analysis is a software engineering task that bridges the gap between system level
requirements engineering and software design .
•Requirements engineering activities result in the specification of software’s operational
characteristics (function, data, and behavior), indicate software's interface with other system elements,
and establish constraints that software must meet. Requirements analysis allows the software engineer
(sometimes called analyst in this role) to refine the software allocation and build models of the data,
functional, and behavioral domains that will be treated by software.
•Requirements analysis provides the software designer with a representation of information, function,
and behavior that can be translated to data, architectural, interface, and component-level designs.
•Finally, the requirements specification provides the developer and the customer with the means to
assess quality once software is built.
5
 Requirements Analysis
• Software requirements analysis may be divided into five areas of effort: (1) problem
recognition, (2) evaluation and synthesis, (3) modeling, (4) specification, and (5) review.
• Initially, the analyst studies the System Specification (if one exists) and the Software Project
Plan.
• It is important to understand software in a system context and to review the software scope
that was used to generate planning estimates.
• Next, communication for analysis must be established so that problem recognition is ensured.
• The goal is recognition of the basic problem elements as perceived by the customer/users.

6
 Requirements Analysis
• Problem evaluation and solution synthesis is the next major area of effort for
analysis.
• The analyst must define all externally observable data objects, evaluate the flow
and content of information, define and elaborate all software functions,
understand software behavior in the context of events that affect the system,
establish system interface characteristics, and uncover additional design
constraints.
• Each of these tasks serves to describe the problem so that an overall approach or
solution may be synthesized.
7
 Requirements Analysis
• For example, an inventory control system is required for a major supplier of auto parts.
• The analyst finds that problems with the current manual system include (1) inability to obtain the status
of a component rapidly, (2) two- or three-day turnaround to update a card file, (3) multiple reorders to
the same vendor because there is no way to associate vendors with components, and so forth.
• Once problems have been identified, the analyst determines what information is to be produced by the
new system and what data will be provided to the system.
• For instance, the customer desires a daily report that indicates what parts have been taken from
inventory and how many similar parts remain.
• The customer indicates that inventory clerks will log the identification number of each part as it leaves
the inventory area.

8
 Requirements Analysis
• Upon evaluating current problems and desired information (input and output), the analyst begins
to synthesize one or more solutions.
• To begin, the data objects, processing functions, and behavior of the system are defined in detail.
• Once this information has been established, basic architectures for implementation are
considered.
• A client/server approach would seem to be appropriate, but does the software to support this
architecture fall within the scope outlined in the Software Plan? A database management system
would seem to be required, but is the user/customer’s need for associativity justified? The
process of evaluation and synthesis continues until both analyst and customer feel confident that
software can be adequately specified for subsequent development steps.
9
 Requirements Analysis
• Throughout evaluation and solution synthesis, the analyst's primary focus is on "what,"
not "how." What data does the system produce and consume, what functions must the
system perform, what behaviors does the system exhibit, what interfaces are defined and
what constraints apply?
• During the evaluation and solution synthesis activity, the analyst creates models of the
system in an effort to better understand data and control flow, functional processing,
operational behavior, and information content.
• The model serves as a foundation for software design and as the basis for the creation of
specifications for the software.

10
 Requirements Elicitation for Software

• Before requirements can be analyzed, modeled, or specified they must be

gathered through an elicitation process.
• A customer has a problem that may be amenable to a computer-based
solution. A developer responds to the customer's request for help.
• Communication has begun. But, as we have already noted, the road from
communication to understanding is often full of potholes.

11
 1) Initiating the Process
• The most commonly used requirements elicitation technique is to conduct a
meeting or interview.
• The first meeting between a software engineer (the analyst) and the customer
can be likened to the awkwardness of a first date between two sides.
• Neither person knows what to say or ask; both are worried that what they do
say will be misinterpreted; both are thinking about where it might lead (both
likely have radically different expectations here); both want to get the thing
over with, but at the same time, both want it to be a success
12
 1) Initiating the Process
• Yet, communication must be initiated. Gause and Weinberg suggest that the analyst start by asking
context-free questions.
• That is, a set of questions that will lead to a basic understanding of the problem, the people who
want a solution, the nature of the solution that is desired, and the effectiveness of the first encounter
itself.
• The first set of context-free questions focuses on the customer, the overall goals, and the benefits.
For example, the analyst might ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need? 13
 1) Initiating the Process
• These questions help to identify all stakeholders who will have interest in the software to be built.
In addition, the questions identify the measurable benefit of a successful implementation and
possible alternatives to custom software development.
• The next set of questions enables the analyst to gain a better understanding of the problem and the
customer to voice his or her perceptions about a solution:
• How would you characterize "good" output that would be generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the environment in which the solution will be used?
• Will special performance issues or constraints affect the way the solution is approached?
14
 1) Initiating the Process
• The final set of questions focuses on the effectiveness of the meeting. Gause and
Weinberg [GAU89] call these meta-questions and propose the following (abbreviated)
list:
• Are you the right person to answer these questions? Are your answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

15
 2) Facilitated Application Specification Techniques

• Too often, customers and software engineers have an unconscious "us and them“
mind-set.
• Rather than working as a team to identify and refine requirements, each
constituency defines its own "territory" and communicates through a series of
memos, formal position papers, documents, and question and answer sessions.
• History has shown that this approach doesn't work very well. Misunderstandings
abound, important information is omitted, and a successful working relationship
is never established.

16
 2) Facilitated Application Specification Techniques

• It is with these problems in mind that a number of independent investigators have developed a
team-oriented approach to requirements gathering that is applied during early stages of analysis
and specification.
• Called facilitated application specification techniques (FAST), this approach encourages the
creation of a joint team of customers and developers who work together to identify the problem,
propose elements of the solution, negotiate different approaches and specify a preliminary set of
solution requirements .
• FAST has been used predominantly by the information systems community, but the technique
offers potential for improved communication in applications of all kinds.

17
 2) Facilitated Application Specification Techniques

• Many different approaches to FAST have been proposed.

• Each makes use of a slightly different scenario, but all apply some variation on the following basic guidelines:
• A meeting is conducted at a neutral site and attended by both software engineers and customers.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the
free flow of ideas.
• A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting.
• A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room
or virtual forum) is used.
• The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a
preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal.
18
 3) Quality Function Deployment
• Quality function deployment (QFD) is a quality management technique that
translates the needs of the customer into technical requirements for software.
• Originally developed in Japan and first used at the Kobe Shipyard of Mitsubishi
Heavy Industries, Ltd. in the early 1970s, QFD “concentrates on maximizing
customer satisfaction from the software engineering process .”
• To accomplish this, QFD emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout the engineering process.
• QFD identifies three types of requirements
19
 3) Quality Function Deployment
• Normal requirements. The objectives and goals that are stated for a product or system during
meetings with the customer.
• If these requirements are present, the customer is satisfied
• Examples of normal requirements might be requested types of graphical displays, specific
system functions, and defined levels of performance.
• Expected requirements. These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them.
• Their absence will be a cause for significant dissatisfaction.
• Examples of expected requirements are, ease of human/machine interaction, overall operational
correctness and reliability, and ease of software installation.
20
 3) Quality Function Deployment
• Exciting requirements. These features go beyond the customer’s expectations and prove
to be very satisfying when present. For example, word processing software is requested
with standard features. The delivered product contains a number of page layout
capabilities that are quite pleasing and unexpected.
• QFD uses customer interviews and observation, surveys, and examination of historical
data (e.g., problem reports) as raw data for the requirements gathering activity.
• These data are then translated into a table of requirements—called the customer voice
table—that is reviewed with the customer. A variety of diagrams, matrices, and
evaluation methods are then used to extract expected requirements and to attempt to
derive exciting requirements.
21
 4) Use-Cases
• As requirements are gathered as part of informal meetings, FAST, or QFD,
the software engineer (analyst) can create a set of scenarios that identify a
thread of usage for the system to be constructed. The scenarios, often called
use-cases, provide a description of how the system will be used.
• To create a use-case, the analyst must first identify the different types of
people (or devices) that use the system or product. These actors actually
represent roles that people (or devices) play as the system operates. Defined
somewhat more formally, an actor is anything that communicates with the
system or product and that is external to the system itself.
22
 4) Use-Cases
• It is important to note that an actor and a user are not the same thing. A typical user may play a
number of different roles when using a system, whereas an actor represents a class of external
entities (often, but not always, people) that play just one role. As an example, consider a machine
operator (a user) who interacts with the control computer for a manufacturing cell that contains a
number of robots and numerically controlled machines.
• After careful review of requirements, the software for the control computer requires four different
modes (roles) for interaction: programming mode, test mode, monitoring mode, and
troubleshooting mode. Therefore, four actors can be defined: programmer, tester, monitor, and
troubleshooter.
• In some cases, the machine operator can play all of these roles. In others, different people may
play the role of each actor.
23
 4) Use-Cases
• Because requirements elicitation is an evolutionary activity, not all actors are identified
during the first iteration.
• It is possible to identify primary actors during the first iteration and secondary actors as
more is learned about the system.
• Primary actors interact to achieve required system function and derive the intended benefit
from the system. They work directly and frequently with the software.
• Secondary actors support the system so that primary actors can do their work.
• Once actors have been identified, use-cases can be developed. The use-case describes the manner in
which an actor interacts with the system. Jacobson suggests a number of questions that should be
answered by the use-case:
24
 4) Use-Cases
• What main tasks or functions are performed by the actor?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?

25
 Analysis Principles
• Over the past two decades, a large number of analysis modeling methods have been developed.
Investigators have identified analysis problems and their causes and have developed a variety of
modeling notations and corresponding sets of heuristics to overcome them. Each analysis method
has a unique point of view. However, all analysis methods are related by a set of operational
principles:
1. The information domain of a problem must be represented and understood.
2. The functions that the software is to perform must be defined.
3. The behavior of the software (as a consequence of external events) must be represented.
4. The models that depict information, function, and behavior must be partitioned in a manner that
uncovers detail in a layered (or hierarchical) fashion.
5. The analysis process should move from essential information toward implementation detail.
26
 Analysis Principles
• By applying these principles, the analyst approaches a problem systematically.
The information domain is examined so that function may be understood more
completely.
• Models are used so that the characteristics of function and behavior can be
communicated in a compact fashion. Partitioning is applied to reduce
complexity.
• Essential and implementation views of the software are necessary to
accommodate the logical constraints imposed by processing requirements and
the physical constraints imposed by other system elements.
27
 Analysis Principles
• In addition to these operational analysis principles, Davis suggests a set of guiding
principles for requirements engineering:
 Understand the problem before you begin to create the analysis model. There is a
tendency to rush to a solution, even before the problem is understood. This often leads to
elegant software that solves the wrong problem!
 Develop prototypes that enable a user to understand how human/machine interaction will
occur. Since the perception of the quality of software is often based on the perception of
the “friendliness” of the interface, prototyping (and the iteration that results) are highly
recommended.

28
 Analysis Principles
 Record the origin of and the reason for every requirement. This is the first step in establishing
traceability back to the customer.
 Use multiple views of requirements. Building data, functional, and behavioral models provide the
software engineer with three different views. This reduces the likelihood that something will be
missed and increases the likelihood that inconsistency will be recognized.
 Rank requirements. Tight deadlines may preclude the implementation of every software
requirement. If an incremental process model is applied, those requirements to be delivered in the
first increment must be identified.
 Work to eliminate ambiguity. Because most requirements are described in a natural language, the
opportunity for ambiguity abounds. The use of formal technical reviews is one way to uncover and
eliminate ambiguity.
29