Requirements Engineering

Requirements engineering – helps software engineers to better understand the problem they will work to solve.  It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the software.  It establishes a solid base for design and construction.

 Key issues:

1.      Understanding the requirements of a problem is among the most difficult tasks that face a software engineer.

2.      Doesn’t the customer know what is required?

3.      Shouldn’t the end-users have a good understanding of the features and functions that will provide benefit?

 

“I know you think you understand what I said, but what you don’t understand is what I said is not what I mean.”

 Requirements Engineering Tasks

1.      Inception

– Software engineers ask a set of context-free questions.  The intent is to establish a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and developer.

 Asking the First Questions

The first set of context-free questions focuses on the customer and other stakeholders, overall goals, and benefits. For example, the requirements engineer 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?

 

The questions help to identify the stakeholders, the measurable benefit of a successful implementation and possible alternatives.

 

The next set of questions enables the software team to gain a better understanding of the problem and allows 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 business environment in which the solution will be used?

·        Will special performance issues or constraints affect the way the solution is approached?

 

The final set of questions focuses on the effectiveness of the communication activity itself.  Gause and Weinberg 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?

 

2.      Elicitation –

 

Why elicitation is difficult: (Christel and Kang)

·        Problems of scope – The boundary of the system is ill-define or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.

·        Problems of understanding – The customers/users 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, omit information that is believed to be “obvious”, specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.

·        Problems of volatility – The requirements change over time.

 Collaborative Requirements Gathering

·        Meetings are conducted 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” 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.

  

3.      Elaboration – focuses on developing a refined technical model of software functions, features, and constraints.

 

Elaboration is an analysis modeling action that is composed of a number of modeling and refinement tasks.  Elaboration is driven by the creation and refinement of user scenarios that describe how the end-user (and other actors) will interact with the system.  Each user scenario is parsed to extract analysis classes – business domain entities that are visible to the end-user.  The attributes of each analysis class are defined and the services that are required by each class are identified.  The relationships and collaboration between classes are identified and a variety of supplementary UML diagrams are produced.

 

The end-result of elaboration is an analysis model that defines the informational, functional, and behavioral domain of the problem.

 

4.      Negotiation – is the process settling down of conflicts between parties.

 Processes involved:

·        Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in priority.

·        Risks 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 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.

 

5.      Specification – means different things to different people.  A specification can be a written document, a set of graphical models, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

 

The specification 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.

 

6.      Validation – examines the specification to ensure that all software requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product.

 

7.      Management – is a set of activities that help the project team identify, control, and track requirement and changes to requirements at nay time as the project proceeds.

Advertisements

One Response to “Requirements Engineering”

  1. David Locke Says:

    If you run with measurable outcomes, you end up with unmeasurable results. ALL delivered application have unmeasurable results. Bad elicitation will make them worse.

    Ask the users of a recently delivered application if they have to use Excel and Access to make up for the deficencies in the enterprise-level applications they use in their day-to-day work. If they do use these tools, then you know that the requirements for the application have failed. The end result of these failures will be an increase in the cost structure of the enterise for a very long time. This increase is not captured by the accounting system. This increase is invisble.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: