Software

Engineering
LECTURE 6
Problems with Requirements
Practices
- We have trouble fully understanding the requirements from the customer.
- We often record the requirements in a messy, unorganized way.
- We don’t spend enough time checking if what we recorded is correct.
- We let changes happen without control, instead of managing them properly.
- Most importantly, we fail to create a strong, clear foundation for the system or software the
user wants.
Problems with Requirements
Practices
Many software developers believe:
•Building software is so exciting that they start right away, even without fully understanding the
needs.
•They think things will become clearer as they build the software.
•They believe project stakeholders will know what they need only after seeing early versions of
the software.
•They feel things change so fast that planning requirements is a waste of time.
•They focus on just getting the software to work, thinking everything else is less important.
These points can be true, especially for small projects that take less than a month. However, for
larger and more complex projects, this approach can cause problems and even lead to project
failure.
Solution: Requirements
Engineering
- This process starts when we communicate about the project and continues when we create
models.
- It allows the requirements engineer to look at:
- The overall context of the software work being done.
- The specific needs that the design and building must meet.
- The priorities that determine the order of tasks.
- The important information, functions, and behaviors that will greatly affect the final design.
Requirements Engineering Tasks
Seven distinct tasks
◦ Inception
◦ Elicitation
◦ Elaboration
◦ Negotiation
◦ Specification
◦ Validation
◦ Requirements Management

Some of these tasks may occur in parallel and all are adapted to the needs of the project
All strive to define what the customer wants
All serve to establish a solid foundation for the design and construction of the software
Requirements Engineering Tasks
Inception
During inception, the requirements engineer asks a set of questions to establish
◦ A basic understanding of the problem
◦ The people who want a solution
◦ The nature of the solution that is desired
◦ The effectiveness of preliminary communication and collaboration between the customer and the
developer

Through these questions, the requirements engineer needs to

◦ Identify the stakeholders
◦ Recognize multiple viewpoints
◦ Work toward collaboration
◦ Break the ice and initiate the communication
Elicitation
Eliciting requirements is difficult because of
◦ Problems of scope in identifying the boundaries of the system or specifying too much technical detail
rather than overall system objectives
◦ Problems of understanding what is wanted, what the problem domain is, and what the computing
environment can handle (Information that is believed to be "obvious" is often omitted)
◦ Problems of volatility because the requirements change over time

Elicitation may be accomplished through two activities

◦ Collaborative requirements gathering
◦ Quality function deployment
Collaborative Requirements
Gathering
Meetings are conducted and attended by both software engineers, customers, and other
interested stakeholders
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" (customer, developer, or outsider) controls the meeting
A "definition mechanism" is used such as work sheets, flip charts, wall stickers, electronic
bulletin board, chat room, or some other virtual forum
The goal is to identify the problem, propose elements of the solution, negotiate different
approaches, and specify a preliminary set of solution requirements
Quality Function Deployment
This is a technique that translates the needs of the customer into technical requirements for
software
It emphasizes an understanding of what is valuable to the customer and then deploys these
values throughout the engineering process through functions, information, and tasks
It identifies three types of requirements
◦ Normal requirements: These requirements are the objectives and goals stated for a product or system
during meetings with the customer
◦ Expected requirements: These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them
◦ Exciting requirements: These requirements are for features that go beyond the customer's expectations
and prove to be very satisfying when present
Elaboration
During elaboration, the software engineer takes the information obtained during inception and
elicitation and begins to expand and refine it
Elaboration focuses on developing a refined technical model of software functions, features, and
constraints
It is an analysis modeling task
◦ Use cases are developed
◦ Domain classes are identified along with their attributes and relationships
◦ State machine diagrams are used to capture the life on an object

The end result is an analysis model that defines the functional, informational, and behavioral
domains of the problem
Developing Use Cases
Step One
Define the set of actors that will be involved in the story
Actors are people, devices, or other systems that use the system or product within the context of
the function and behavior that is to be described
Actors are anything that communicate with the system or product and that are external to the
system itself
Step Two
Develop use cases, where each one answers a set of questions
Questions Commonly Answered
by a Use Case
Who is the primary actor(s), the secondary actor(s)?
What are the actor’s goals?
What preconditions should exist before the scenario begins?
What main tasks or functions are performed by the actor?
What exceptions might be considered as the scenario is described?
What variations in the actor’s interaction are possible?
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?
Elements of the Analysis Model
Scenario-based elements - Describe the system from the user's point of view using scenarios
that are depicted in use cases and activity diagrams
Class-based elements Identify the domain classes for the objects manipulated by the actors, the
attributes of these classes, and how they interact with one another, they utilize class diagrams to
do this
Behavioral elements – Use state diagrams to represent the state of the system, the events that
cause the system to change state, and the actions that are taken as a result of a particular event;
can also be applied to each class in the system
Flow-oriented elements – Use data flow diagrams to show the input data that comes into a
system, what functions are applied to that data to do transformations, and what resulting
output data are produced
Negotiation
During negotiation, the software engineer reconciles the conflicts between what the customer
wants and what can be achieved given limited business resources
Requirements are ranked (i.e. prioritized) by the customers, users, and other stakeholders
Risks associated with each requirement are identified and analyzed
Rough guesses of development effort are made and used to assess the impact of each
requirement on project cost and delivery time
Using an iterative approach, requirements are eliminated, combined and / or modified so that
each party achieves some measure of satisfaction
Art of Negotiation
Recognize that it is not competition
Map out a strategy
Listen actively
Focus on the other party’s interests
Don’t let it get personal
Be creative
Be ready to commit
Specification
A specification is the final work product produced by the requirements engineer
It is normally in the form of a software requirements specification
It serves as the foundation for subsequent software engineering activities
It describes the function and performance of a computer-based system and the constraints that
will govern its development
It formalizes the informational, functional, and behavioral requirements of the proposed
software in both a graphical and textual format
Typical Contents of a Software
Requirements Specification
Requirements
◦ Required states and modes
◦ Software requirements grouped by capabilities (i.e., functions, objects)
◦ Software external interface requirements
◦ Software internal interface requirements
◦ Software internal data requirements
◦ Other software requirements (safety, security, privacy, environment, hardware, software, communications,
quality, personnel, training, logistics, etc.)
◦ Design and implementation constraints

Qualification provisions to ensure each requirement has been met

◦ Demonstration, test, analysis, inspection, etc.

Requirements traceability
◦ Trace back to the system or subsystem where each requirement applies
Validation
During validation, the work products produced as a result of requirements engineering are
assessed for quality
The specification is examined to ensure that
◦ all software requirements have been stated unambiguously
◦ inconsistencies, omissions, and errors have been detected and corrected
◦ the work products conform to the standards established for the process, the project, and the product

The formal technical review serves as the primary requirements validation mechanism
◦ Members include software engineers, customers, users, and other stakeholders
Requirements Management
During requirements management, the project team performs a set of activities to identify,
control, and track requirements and changes to the requirements at any time as the project
proceeds
Each requirement is assigned a unique identifier
The requirements are then placed into one or more traceability tables
These tables may be stored in a database that relate features, sources, dependencies,
subsystems, and interfaces to the requirements
A requirements traceability table is also placed at the end of the software requirements
specification