Chapter 5 – Understanding Requirements

Overview

• Requirements engineering helps software engineers better understand the problems they are trying to solve.
• Building an elegant computer solution that ignores the customer’s needs helps no one.
• It is very important to understand the customer’s wants and needs before you begin designing or building a computer-based solution.
• The requirements engineering process begins with inception, moves on to elicitation, negotiation, problem specification, and ends with review or validation of the specification.
• The intent of requirements engineering is to produce a written understanding of the customer’s problem.
• Several different work products might be used to communicate this understanding (user scenarios, function and feature lists, analysis models, or specifications).

 

Requirements Engineering

• Must be adapted to the needs of a specific process, project, product, or people doing the work.
• Begins during the software engineering communication activity and continues into the modeling activity.
• In some cases requirements engineering may be abbreviated, but it is never abandoned.
• It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem.

 

Requirements Engineering Tasks

• Inception (software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers)
• Elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis)
• Elaboration (focuses on developing a refined technical model of software function, behavior, and information)
• Negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs)
• Specification (written work products produced describing the function, performance, and development constraints for a computer-based system)
• Requirements validation (formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products)
• Requirements management (activities that help project team to identify, control, and track requirements and changes as project proceeds, similar to  software configuration management (SCM) techniques

 

Initiating Requirements Engineering Process

• Identify stakeholders
• Recognize the existence of multiple stakeholder viewpoints
• Work toward collaboration among stakeholders
• These context-free questions focus on customer, stakeholders, overall goals, and benefits of the system
• Who is behind the request for work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution needed?
• The next set of questions enable developer to better understand the problem and the customer’s perceptions of the solution
• How would you characterize good output form a successful solution?
• What problem(s) will this solution address?
• Can you describe the business environment in which the solution will be used?
• Will special performance constraints affect the way the solution os approached?
• The final set of questions focuses on communication effectiveness
• Are you the best person to give “official” answers to these questions?
• Are my questions relevant to your problem?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

 

Eliciting Requirements

• Goal is to identify the problem, propose solution elements, negotiate approaches, and specify preliminary set of solutions requirements
• Collaborative requirements gathering guidelines
• Meetings attended by both developers and customers
• Rules for preparation and participation are established
• Flexible agenda is used
• Facilitator controls the meeting
• Definition mechanism (e.g. stickers, flip sheets, electronic bulletin board) used to gauge group consensus

 

Quality function deployment (QFD)

• Quality management technique that translates customer needs into technical software requirements expressed as a customer voice table
• Identifies three types of requirements (normal, expected, exciting)
• In customer meetings function deployment is used to determine value of each function that is required for the system
• Information deployment identifies both data objects and events that the system must consume or produce (these are linked to functions)
• Task deployment examines the system behavior in the context of its environment
• Value analysis is conducted to determine relative priority of each requirement generated by the deployment activities

 

Elicitation Work Products

• Statement of need and feasibility
• Bounded statement of scope for system or product
• List of stakeholders involved in requirements elicitation
• Description of system’s technical environment
• List of requirements organized by function and applicable domain constraints
• Set of usage scenarios (use-cases) that provide use insight into operation of deployed system
• Prototypes developed to better understand requirements

 

Elicitation Problems

• Scope  – system boundaries ill-defined
• Understanding – customers not sure what’s needed or can’t communicate it
• Volatility – requirements changes over time

 

Developing Use-Cases

• Each use-case tells stylized story about how end-users interact with the system under a specific set of circumstances
• First step is to identify actors (people or devices) that use the system in the context of the function and behavior of the system to be described
• Who are the primary (interact with each other) or secondary (support system) actors?
• What are the actor’s goals?
• What preconditions must exist before story begins?
• What are the main tasks or functions performed by each actor?
• What exceptions might be considered as the story is described?
• What variations in actor interactions are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor need to inform the system about external environment changes?
• What information does the actor desire from the system?
• Does the actor need to be informed about unexpected changes?
• Next step is to elaborate the basic use case to provide a more detailed description needed to populate a use-case template

 

Use-case template

• Use Case Name
• Primary actor
• Goal in context
• Preconditions
• Trigger
• Scenario details
• Exceptions
• Priority
• When available
• Frequency of use
• Channel to actor
• Secondary actors
• Channels to secondary actors
• Open issues

 

Analysis Model

• Intent is to provide descriptions of required information, functional, and behavioral domains for computer-based systems
• Analysis Model Elements
• Scenario-based elements (use cases describe system from user perspective)
• Class-based elements (relationships among objects manipulated by actors and their attributes are depicted as classes)
• Behavioral elements (depict system and class behavior as states and transitions between states)
• Flow-oriented elements (shows how information flows through the system and is transformed by the system functions)

 

Analysis Patterns

• Suggest solutions (a class, a function, or a behavior) that can be reused when modeling future applications
• Can speed up the development of abstract analysis models by providing reusable analysis models with their advantages and disadvantages
• Facilitate the transformation of the analysis model into a design model by suggesting design patterns and reliable solutions to common patterns 

 

Negotiating Requirements

• Intent is to develop a project plan that meets stakeholder needs and real-world constraints (time, people, budget) placed on the software team
• Negotiation activities
• Identification of system key stakeholders
• Determination of stakeholders’ “win conditions”
• Negotiate to reconcile stakeholders’ win conditions into “win-win” result for all stakeholders (including developers)
• Goal is to produce a win-win result before proceeding to subsequent software engineering activities

 

Requirement Review (Validation)

• Is each requirement consistent with overall project or system objective?
• Are all requirements specified at the appropriate level off abstraction?
• Is each requirement essential to system objective or is it an add-on feature?
• Is each requirement bounded and unambiguous?
• Do you know the source for each requirement?
• Do requirements conflict with one another?
• Is each requirement achievable in the technical environment that will house the system or product?
• Is each requirement testable once implemented?
• Does the requirements model reflect the information, function, and behavior of the system to be built?
• Has the requirements model been partitioned in a way that exposes more detailed system information progressively?
• Have all the requirements patterns been properly validated and are they consistent with customer requirements?