ExpressionLab

If you don't know, Software Engineering Radio is a series of podcasts that covers all topics of software engineering. It is a very useful resource for professional software developers. In episode 114, Christof Ebert talks about requirements engineering. Here is the summary.

Introduction

Christof has seen from a number of projects and also from surveys in the industry that software projects have many problems. The reasons are many faults but one thing which is seen repeatedly is that requirements engineering seems to be the number one technical topic where projects either succeed or fail.

Requirements always change and if this is not well addressed, projects run into time and budget constraints and may be with insufficient quality. Things can go wrong up to the level of customers finding that the product is not really what they needed. That is the key reason requirements engineering is a major challenge in today's software development.

So requirements engineering is about defining what the system should do, what the value of the product is. This product can be a release of a software, a tool, a big IT system, an embedded software system, etc.

However, there is a relation between the "what" and the "how". In order to find out what should be done in a project, you need to address how it should be done because only by understanding how you will address certain issues, you are better positioned to ask questions to customers to know what are their needs. Also, it is useless to come up with requirements that are not implementable because they are too complicated or just not feasible.

Typical Pitfalls

Requirements engineering is not so difficult if we addressed all the risks. These can be of three categories:

1. Wrong requirements

   Like when you produce a nice product in a market that doesn't need it, or when a competitor has a key functionality which you don't have.

2. Missing requirements

   This is usually a result of misunderstanding customers or ignoring different users of the system with different levels of skills. If you talk to the wrong people, you have missing requirements.

3. Changing requirements

   As a rule, requirements change. And if you are not capable of addressing changes by quality control, configuration management, etc, this will kill any project because you can't see where the changes impact is.

Types of Requirements

There are three main types of requirements:

1. Market requirements

   These are the requirements from the user perspective. This is the problem space; what they think the system should do.

2. Product requirements

   Usually called the feature set, these are how the product is addressing those market requirements. This is the solution space; what the product can offer.

3. Component requirements

   This is how the product requirements can be translated into product functionality.

Also, you should differentiate two types of requirements:

1. Functional requirements

   These are the basic functions of the system.

2. Non-functional requirements

   Examples include how fast the product should process a file, how secure is it, etc.

Activities

The word "engineering" implies that there is a systematic approach to dealing with requirements. This includes a set of activities:

1. Elicitation

   This gives you the "What". This is not just collecting requirements, it includes:

   • Defining dependencies
   • Understanding the customer's real needs. Normally you don't fully understand the business model, context, usage models, market, etc. Make sure you understand customer needs. Put your self in the position of the standard user.
   • Knowing who to ask and considering different users. For example, managers usually care about time frame and economic requirements instead of functionality. Prepare a few questions that help you find out if they are you the right person to ask about a certain feature.
   • Don't spend too much effort trying to expect all possible potential requirements before the project starts. Remember, requirements change.
   • The outcome is:
     1. A concise vision on what value is to deliver
     2. A list of needs
     3. A draft requirements specifications

2. Specifications

   This is about clearly describing requirements. The target is to get mutual understanding of what should be done and how it should be done.

   • You need to get something on paper to reference functionality; like use cases
   • Outcome: a written baseline about the requirements
   • How to write specs that are not easy to misunderstand:
     • Specs are not a purpose in itself
     • Writing a glossary or dictionary to make sure you and your client understand each other
     • Using diagrams with description
     • Be precise. Don't use words like: might, perhaps, at least, etc. This makes it difficult to implement. Use numbers where possible.
     • Use modeling to have better understanding. Use UML or even plain text.

3. Analysis

   This builds the bridge between the what and the how.

   • Helps to address the write questions
   • Helps you decide what kind of components, language, architecture, etc to use. So helps reduce the solution space
   • Help you realize what constraints, priorities are there
   • Helps you identify what are most effective requirements in terms of functionality and cost
   • Prioritization analysis results in dependency graph. You would know if you remove a feature what market requirement will be missed

4. Validation

   This about making sure you have addressed the right topics and understood what is needed to relate the product to customer/market needs.

   • It builds a basis for test cases
   • Good requirements should be achievable (technical and budget), testable, and implementable

5. Commitment

   Now, we know customer needs, we know the way we want to address these needs.

   • You need to map them into releases with time constraints
   • Commit internally and externally: capacity and needs
   • Don't commit too early until you are certain about all requirements
   • Commit only to a subset of the requirements in initial iterations and once you learn more in the subsequent iterations, you can commit to more
   • Make sure the parts that are not clear yet have no architectural impact. You need to know the nonfunctional requirements very early. But don't keep the analysis phase too long

6. Management

   Requirements change and you need to manage these changes. This is actually the bridge to the development process.

   • Make sure you always have a clear baseline
   • When there is a change, trace it to the downstream and upstream requirements to know the side impacts
   • Use modeling tools to build and maintain models
   • Make sure u always have one main baseline
   • This gives you Visibility:
     • Customer requirements and products requirements
     • Tracking changes; amount, impact, capability to handle. This can be used later to review
     • Status info about to which degree have you implemented a certain requirement, to which degree can you relate that to project progress. This helps you detect problems early.

Summary

• Requirements engineering needs discipline
• Requirements engineering is team work
• Requirements engineering is about risk management
• Requirements engineering is not linked to a certain development process
• Requirements engineering is a part of the project that consumes resources but helps you handle changes, keep deadlines and deliver high quality products
• Requirements engineering is not about formalism or unnecessary overheads

I hope you find this useful.

Did you like this article? Bookmark it: