Elicitation and SRS

15-jobs-that-pay-under-15-an-hour-private-detective-investigators
http://wallstreetinsanity.com/15-jobs-that-pay-under-15-an-hour/

Eliciting requirements is an effort to get information from stakeholders and subject matter experts. Elicitation is not a step, it is a set of techniques that must be applied during the requirements phase of the Software Development Life Cycle. It is common to use the terms “gathering” and “eliciting” to refer to the same process. However, “eliciting more accurately describes the process of revealing not-so-observable requirements”, it consists in a planned and deliberate search, and gathering is more about taking what you see.

Projects tend to fail when the requirements are not well defined, this might happen because people involved in the project dont’t know what the real problem is. Here is a 10 step guide to detect the real problem.

So, you discovered the problem, now the application of elicitation techniques comes to action. The most common and effective techniques are:

  • Interviews: It’s used frequently by business analysts, it has to be one-to-one and open ended questions.
  • Brainstorming: This group technique takes place in two sequential activities. The first part consists in raising as many ideas as possible. The second part analyzes and organizes the ideas.
  • Focus groups: They bring together knowledgeable interested parties to examine a topic. These groups tend to be expensive to make and are used most commonly in marketing.
  • Requirements workshops: They bring together as broad a group of stakeholders, they have to keep the whole group involved.
  • Tests: They can be static or dynamic. Static testing reviews requirements directly, while dynamic testing consists in testing the code with previously designed tests. The effectivity of dynamic testing relies on the quality of the test, if it’s not well developed, the project will fail.
  • Project-related documents: It’s important to do background research that is not specific to the project.
  • Observing: Developers elicit requirements
    requirements_accavdar-e1318187040437
    watching workers with more experience in the topic.
  • Learning to do de work: It’s about going a step further of observing, it can make you realize things that weren’t so evident while watching others.

It’s not enough to use just one of them, I recommend to use a few, group and individual ones, to make and effective elicitation. Notice that most of these techniques can be used in other disciplines, not just in software engineering.

After the requirements elicitation, it’s necessary to make a Software Requirements Specification (SRS), which is a description of the purpose and environment for software under development. According to Margaret Rouse, “it fully describes that the software will do and how it will be expected to perform”.

requirements_accavdar-e1318187040437
http://www.cavdar.net/2011/10/10/characteristics-of-a-good-software-requirements-specification-srs/

To make your life easier (or at least to write the SRS more easily), you can follow the next steps:

  1. Create a SRS document template, or search for one. You can check the IEEE template here.
  2. Make a list with the requirements.
  3. Define the functions of the software.
  4. Create use cases for the major sub-processes.
  5. Define the user interface.
  6. Define hardware interfaces.
  7. Define the process flow.
  8. Determine business rules.
  9. Define performance.
  10. Make diagrams to illustrate the process.
  11. Compile the SRS document.

Source