Question

“Progressive refinement of details” is the right approach when developing software requirements. Describe in 2-3 paragraphs or visually portray a good requirement development framework that will take this progressive refinement into account.

Include the following in your answer:

• The different phases within the requirement development
  • Elicitation, analysis, specification, and validation
• The different interactions among these phases
• An overall process where the different phases will feed each other
  • Analysis to feedback to elicitation for clarification
  • Specification to feedback to analysis to close any identified gaps
  • Validation to specification for rewrite
  • Validation to elicitation to confirm and correct
  • Validation to analysis for re-evaluate some of the requirement

Answer 1

Definition: Requirements define the capabilities that a system must have (functional) or properties of that system (non-functional) that meet the users' needs to perform a specific set of tasks (within a defined scope).

Analyzing, Refining & Decomposing requirements include the following eleven (11) steps:

1. Assess each top-level requirement for feasibility (see Feasibility Assessment) of implementation, consistency within program constraints, and its ability to be verified. If the requirement is impossible to implement within cost and schedule constraints, it must be identified as an issue and resolved by adjusting budget, relaxing schedule, and changing or eliminating the requirement.
2. Use functional or object-oriented analysis to define a functional architecture that can be used as a basis for allocating requirements.
3. Allocate all system, subsystem, and interface requirements to appropriate hardware and software configuration items. Ensure each requirement:
   • Is written as a single definitive statement.
   • Has a unique identification number for tracking purposes.
   • Can be traced to a higher level source requirement or analysis.
   • Has been allocated to a specific Computer Software Configuration Item (CSCI).
4. Ensure that each performance requirement has one or more corresponding verification requirements. Involve those who will perform testing activities to ensure that requirements are testable. The specification verification requirement should define a means of objective measurement.
5. Identify analyses, trade studies, prototyping, and demonstration efforts for risk reduction, considering the following:
   • Completeness: Are all higher level requirements allocated?
   • Consistency: Is the content, format, and notation from requirement to requirement, and specification to specification similar?
   • Feasibility: Can the requirement be met?
   • Balance: What are the trade-offs between requirements?
   • Verifiability/testability: Can the requirement be objectively verified?
   • Human factors: Is the design consistent with sound human factors principles?
6. Complete the definition of derived software requirements and examine them for consistency with system requirements, feasibility, and the effects of various implementation strategies. Monitor derived requirements size volatility since derived requirements are often a significant source of software size growth.
7. Apply early aggressive activities to verify that software intended for reuse fits the following criteria:
   • The advertised performance of the software to be reused satisfies performance requirements.
   • The software to be reused exists and is available.
   • The actual performance of the software to be reused satisfies performance requirements and does not have inherent shortfalls that will lead to additional growth.
   • There is a plan to address future upgrades/support of the reused software.
8. Ensure developers flow top level requirements down to lower level specifications and to lower tier suppliers, including software configuration item specifications.
9. Verify CSCI-to-CSCI and CSCI-to-Hardware Configuration Item (HWCI) interface requirements identification and definition.
10. Verify that an adequate and compatible set of tools are in place to capture multi-level requirements (systems down through software) and design evolution.
11. Use operational scenarios to the extent possible to demonstrate, or bring to life, what the requirements are trying to capture. (Operational scenarios portray the product, end user, and other entities in the intended environment, and are a useful tool for discovering and refining requirements.)

Requirement Engineering phases:

Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system. Requirements Engineering Process consists of the following main activities:

• Requirements elicitation
• Requirements specification
• Requirements verification and validation
• Requirements management

Requirements Elicitation:
It is related to the various ways used to gain knowledge about the project domain and requirements. The various sources of domain knowledge include customers, business manuals, the existing software of same type, standards and other stakeholders of the project.
The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc. Some of these are discussed here. Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage.

Requirements specification:
This activity is used to produce formal software requirement models. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality. During specification, more knowledge about the problem may be required which can again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.

Requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:

• The requirements should be consistent with all the other requirements i.e no two requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable

Requirements management:
Requirement management is the process of analyzing, documenting, tracking, prioritizing and agreeing on the requirement and controlling the communication to relevant stakeholders. This stage takes care of the changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by the end users at later stages too. Being able to modify the software as per requirements in a systematic and controlled manner is an extremely important part of the requirements engineering process

Validation to specification for rewrite

Design of real-time/concurrent systems requires formal approaches in order to facilitate verification and validation at each step. Methods based on formal logic have been previously suggested but they often work only in a specific domain and are generally only possible with specialized users. In an attempt to overcome these two restrictions, this paper proposes a method based on rewriting logic with user-friendly tools to increase software reliability. Different tools are proposed to support this approach: a graphical editor for the specification of the structure and the behaviour of objects, a prototype generator, and an inference engine for rule validation based on rewriting logic decidability.

Validation to analysis for re-evaluate some of the requirement

Check If The Requirements Are Related To The Project Goal

Sometimes stakeholders have their own expertise, which they expect to come in the system under development. They don’t even think whether that requirement would be relevant to the project in hand. Make sure to identify such requirements. Try to avoid all irrelevant requirements during the first phase of the project development cycle.

In short, the Requirements Specification (SRS) doc should address the following:

• Project functionality (What should be done and what should not be done).
• Software, Hardware interfaces, and the user interface.
• System Correctness, Security and performance criteria.
• Implementation issues (risks) if any.