Let’s learn about some requirements

In software engineering, we have plenty kind of requirements, but in this blog we are really interested in to kinds of them. The software requirements elicitation and software requirements specification.

requirements

Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as “requirement gathering”.

The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process.

In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation:

  1. 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.
  2. 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.
  3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility

Requirements quality can be improved through these approaches:

  1. Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
  2. Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the
    .
  3. Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects.
  4. Consistent use of templates. Producing a consistent set of models and templates to document the requirements.
  5. Documenting dependencies. Documenting dependencies and interrelationships among requirements.
  6. Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions.

A guideline of steps for doing this would be:

  1. Identify the real problem, opportunity or challenge
  2. Identify the current measure(s) which show that the problem is real
  3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it
  4. Identify the “as-is” cause(s) of the problem, as it is the causes that must be solved, not the problem directly
  5. Define the business “whats” that must be delivered to meet the goal measure(s)
  6. Specify a product design how to satisfy the real business requirements

This is a sequence that Goldsmith suggested in 2004.

————————————————————————-

A software requirements specification (SRS) is a description of a software system to be developed. It lays out functional and nonfunctional requirements, and may include a set of use cases that describe user interactions that the software must provide.

Software requirements specification establishes the basis for an agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do. Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules.Software requirements specification prevents software projects from failure.

SRS STRUCTURE 

An example organization of an SRS is as follows:[5]

    • Purpose
    • Definitions
    • System overview
    • References
  • Overall description
    • Product perspective
      • System Interfaces
      • User Interfaces
      • Hardware interfaces
      • Software interfaces
      • Communication Interfaces
      • Memory Constraints
    • Design constraints
      • Operations
      • Site Adaptation Requirements
    • Product functions
    • User characteristics
    • Constraints, assumptions and dependencies
  • Specific requirements
    • External interface requirements
    • Functional requirements
    • Performance requirements
    • Logical database requirement
    • Software System attributes
      • Reliability
      • Availability
      • Security
      • Maintainability
      • Portability
    • others..

GOALS

The Software Requirements Specification (SRS) is a communication tool between stakeholders and software designers. The specific goals of the SRS are:

  • Facilitating reviews
  • Describing the scope of work
  • Providing a reference to software designers (i.e. navigation aids, document structure)
  • Providing a framework for testing primary and secondary use cases
  • Including features to customer requirements
  • Providing a platform for ongoing refinement (via incomplete specs or questions)

Reliability Availability Security Maintainability Portability.

Extending what we learn. I will leave 2 videos that will help you get all the ideas together.

Software Requirements Elicitation Introduction

Software Requirements Specification

The bast mayority of information gathered in here was extracted from: https://en.wikipedia.org/wiki/Requirements_elicitation#Sequence_of_steps & https://en.wikipedia.org/wiki/Software_requirements_specification