Software Requirements Elicitation and Specification

 

  • Requirement elicitation: Is the first step of creating a project. The client tells the programmer what they expect the program to do and how to do it. The information can be retrieved by interviews, observation, brainstorming, etc. The general process can be described as Discovering the needs of the costumer. (Discovering the needs of the costumer)
  • Requirement specification: This is the process of documenting the previous requirements and analyzing them in order to optimize the project

 

Goldsmith, R. (2015). Use elicitation techniques to discover software requirements. October 28th, 2016, de Search Software quality Sitio web: http://searchsoftwarequality.techtarget.com/feature/Use-elicitation-techniques-to-discover-software-requirements

Rouse, M. (2007). software requirements specification (SRS). October 28th, 2016, de Search Quality Software Sitio web: http://searchsoftwarequality.techtarget.com/definition/software-requirements-specification


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
    Continue reading "Elicitation and SRS"

Requirements Elicitation and Specification

roll-the-dice-craps-board-game-points-122427.jpeg

Elic… what? that sounds complicated. Well, it actually isn’t. I’ve talked about functional and non-functional requirements before, but this is something completely different.

As you may remember, the first step of the SDLC is collecting infomation, requirements elicitation and specification are part of this step.

Requirement elicitation, is actually the first thing you have to do in the software life-cycle and is the practice of finding out what the customer or user wants. In an informal concept, is more like a wish list of requirements. But there are many problems that are almost impossible to avoid because it depends more of the customer, for example: he doesn’t know exactly what he wants, he thinks that some specifications are obvious or his needs changed and want the software to do something else.

Requirements elicitation practices include:

  • Interviews
  • Questionnaires
  • User observation
  • Workshops
  • Brainstorming
  • Use cases
  • Role playing
  • Prototyping

Once you know what the customer wants, you’ll be able to do the software requirement specification (SRS), which is a process of recording the client’s requirements in any form, like a document, a graphical representation, a graph, a pie, a cake, brownies, etc.

SRS also contains the functional and non-functional requirements and other specification types, for example: performance, maintainability, reliability, resource, etc.

Sources:

http://www.tutorialspoint.com/software_engineering/software_requirements.htm

https://en.wikipedia.org/wiki/Requirements_elicitation

http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=12553


Software Requirements

In order to define what a piece of software can do, you have to define clearly the functions and requirements that it must contain for the customer to be satisfied and your team to know what to do and how.

The goal is to arrive at a Software Requirements Specification (SRS) Document, a spec sheet that details what the software can do.
Photo by Nathanael Coyne on Flickr. CC BY-NC-ND
Requirement Engineering is a discipline that aims towards understanding client's requirements and translating them into technical and detailed specifications for the developers, it consists of four basic steps:

  1. Feasibility Study: Knowing if what the client wants is possible, taking into account technical, economical, and organizational aspects. This stage outputs the feasibility study report.
  2. Requirement Gathering: Getting the expectations of what the software should do from the client and end-users. Requirements must be clear, correct, consistent, coherent, modifiable, verifiable, unambiguous, traceable, and from a credible source.
  3. Software Requirement Specification: After collecting information from all the people involved, an engineer creates the SRS, where the client's specifications are expressed in natural language, and all the technical aspects of the project are detailed in order for it to be useful for the development team, including pseudo code and GUI sketches.
  4. Software Requirement Validation: Between the developer and client, the specifications are reviewed to verify that they are correct, within scope, and achievable.

REQUIREMENT ELICITATION
It is an organized process to gather requirements for the software, it has four steps.

Requirement elicitation process

First the developer gets the requirements from the client, then they are prioritized and categorized, next they are reviewed with the stakeholders to remove any ambiguity or doubts about the requirements, finally, they are documented correctly for the next phases of development.

One or more of these methods can be Continue reading "Software Requirements"

Software Requirements

In order to define what a piece of software can do, you have to define clearly the functions and requirements that it must contain for the customer to be satisfied and your team to know what to do and how.

The goal is to arrive at a Software Requirements Specification (SRS) Document, a spec sheet that details what the software can do.
Photo by Nathanael Coyne on Flickr. CC BY-NC-ND
Requirement Engineering is a discipline that aims towards understanding client's requirements and translating them into technical and detailed specifications for the developers, it consists of four basic steps:

  1. Feasibility Study: Knowing if what the client wants is possible, taking into account technical, economical, and organizational aspects. This stage outputs the feasibility study report.
  2. Requirement Gathering: Getting the expectations of what the software should do from the client and end-users. Requirements must be clear, correct, consistent, coherent, modifiable, verifiable, unambiguous, traceable, and from a credible source.
  3. Software Requirement Specification: After collecting information from all the people involved, an engineer creates the SRS, where the client's specifications are expressed in natural language, and all the technical aspects of the project are detailed in order for it to be useful for the development team, including pseudo code and GUI sketches.
  4. Software Requirement Validation: Between the developer and client, the specifications are reviewed to verify that they are correct, within scope, and achievable.

REQUIREMENT ELICITATION
It is an organized process to gather requirements for the software, it has four steps.

Requirement elicitation process

First the developer gets the requirements from the client, then they are prioritized and categorized, next they are reviewed with the stakeholders to remove any ambiguity or doubts about the requirements, finally, they are documented correctly for the next phases of development.

One or more of these methods can be Continue reading "Software Requirements"

Essentials of Elicitation & Specification

The first step of the Software Development Lifecycle is Functional & non Functional Requirement Gathering , it is the result from the specification of the informal ideas a client has about a product. The goals of this phase are to define the needed software and hardware. It is a really important phase because failures at this stage may increase the cost of development in higher stages to ensure the customer needs.

gerard.rendell - Elicitation
gerard.rendell –
Elicitation

There are two factors to consider:

Initial Input: The idea of how a system will be created considering the needs of the client and defining a problem to be solved.

Desired Output: The requirements must be as specific as possible so the problem that needs to be solved can be completely understood.

Requirements Elicitation is mainly understanding and analyzing all of the requirements a client has for a system. Developers & engineers work closely with clients to understand the problems that need to be solved and what functionality a system should have and what hardware is optimal.

The problem is that clients usually do not have a clear idea of what they want or need and if there are many stakeholders, they will most surely have conflicting ideas. The conditions need to be met for the client to be able to solve a specific problem or achieve a certain objective and it must satisfy specific contracts, standards and specifications.

Requirements Elicitation – basic customer idea and definition.

Requirements Specification – Basic developer design and technical specifications.

Requirement analysis normaly uses one of two models: Dynamic model or Object Model. These specifications use formal (exact mathematical syntax or semanic syntax) or semi-formal notation (like UML).

In general this is a phase of understanding the stated problem that the client has and how it should be Continue reading "Essentials of Elicitation & Specification"