Requirements Engineering

LECTURE 3

Introduction

Understanding the requirements of a problem is one of the difficult tasks of a software engineer.

An excerpt from a book on requirements practices:

                     “Its your worst nightmare. A customer walks into your office, sits down, looks you straight in the eye, and says, “I know you think you understand what I said, but what you don’t understand is what I said is not what I mean”

Why Projects Fail?  

• Designing and building computer software is challenging, creative and fun

• Many software developers want to jump right in before they have a clear understanding of what is needed.
  
• Wrong concepts about projects:

                    things will become clear as they are built
                    Stakeholders will be able to better  understand need only after
                    examining early iterations of the software
                    Things change rapidly that requirements engineering is a waste of time
                    Bottom line is producing a working program and all else is secondary

 Requirements Engineering

• Provides a solid approach for addressing challenges in software project.
• Must be adapted to the needs of the:  Process, project and product and the people doing the work
• Begins during the communication activity and continues into the modeling activity.
• Helps software engineers to better understand the problem they will work to solve

 
Software Team’s Duty

They must: 

• adapt its approach to Requirements engineering
• Make a real effort to understand the requirements of a problem before the team attempts to solve the problem
• Provides the appropriate mechanism for understanding:

                What the customer wants, Analyzing need, Assessing feasibility, Negotiating a reasonable solution, Specifying the solution unambiguously, Validating the specification                 Managing the requirements as they are transformed into an operational system

How Users and Developers View Each Other

Requirements Engineering Tasks

• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Management

               Some occur in parallel and all are adapted to the needs of the project

                All strive to establish a solid foundation for the design and construction of what   the customer gets

Inception

• A task that defines the scope and nature of the problem to be solved.
• Software engineers asks a context-free questions
• Intent is to establish a basic understanding of:

                        the problem, the people who want a solution, nature of the solution that is desired and the effectiveness of preliminary communication and collaboration between the customer and the developer

 Elicitation

• Ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system of product fits into the needs of the business and finally, how the system or product is to be used on a day-to-day basis.

Why Elicitation is Difficult?

• Problems of scope - the boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse rather than clarify overall system objectives.
• Problems of understanding –the customers/user are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, etc.
• Problems of volatility – the requirements change over time

To help overcome these, requirements engineer must approach the requirements gathering activity in an organized manner.

Elaboration

• Basic requirements (obtained from the customer during inception and elicitation) are refined and modified
• Focuses on developing a refined technical model of software functions, features and constraints.
• Driven by the creation and refinement of user scenarios
• End-result: analysis model that defines the informational, functional and behavioral domain of the problem.

 Negotiation

• There’s no winner and loser in an effective negotiation
• Customers usually ask for more than can be achieved, given limited resources
• Some proposed conflicting requirements
• The requirements engineer must reconcile these conflicts through a process of negotiation

How is Negotiation done?

• Customers, users and other stakeholders are asked to rank requirements and then discuss conflicts in priority
• Risk associated with each requirement are identified and analyzed
• Rough “guestimates” of development effort are made and used to assess the impact of each requirement on cost and delivery time.
• Using iterative approach, requirements are eliminated, combined and/or ,modified so that each party achieves some measure of satisfaction

 Specification

• Can be written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.
• It is the final work product produced by the requirements engineer.
• 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.

 Validation

• Work products produced are assessed for quality in this step
• A task which examines the specification to ensure that all software requirements have been stated unambiguously;
• That inconsistencies, omissions and errors have been detected and corrected
• That work products conform to the standards established for the process, project and the product

 Formal Technical Review

• Primary requirements validation mechanism
• The review team that validates the requirements includes software engineers, customers, users, and other stakeholders who examine the specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies, conflicting requirements or unrealistic requirements
  

 Requirements Management

• A set of activities that help the project team identify, control and track requirements at any time as the project proceeds
• Begins with identification
• Each requirement is assigned a unique identifier
• 
  
  Traceability tables are developed
  
  
  

Ariane 5 Launcher explosion case

Traceability Tables

• Source traceability table
• Identifies the source of each requirement
• Dependency traceability table
• Indicates how requirements are related to one another.
• Subsystem traceability table
• Categorizes requirements by the subsystems they govern
• Interface traceability table
• Shows how requirements relate to both internal and external system interfaces

Features traceability table