Little Insight With Software Requirement Engineering

Aashim Bajracharya

Software Design Analyst

Software Requirements are description of features and functionalities of the target system. Requirements provide the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.

The main purpose of collecting requirements process is gathering stakeholder requirements in a project. Requirements collection is performed as part of the project definition process. Requirements collection is started when the project need is first clarified and the project solution is to be proposed. Requirements refinement continues after the project is selected and as the scope is defined, aligned and approved. Collecting Requirements is an important activity in project management. Because requirements of a project define the project scope. And any weakness in requirements management will cause scope issues respectively.

 

Odoo CMS - a big picture


There are certain techniques to collect requirements for the Software Development and they are stated below:

  • Interviewing

It can be done through a meeting, through a phone call or through emails. In this collect requirements technique Project Manager interviews the stakeholders to get their requirements. There can be a checklist, a list of questions or project manager can just ask the stakeholders to express their expectations from the project in a free form. Project manager notes down and stores the requirements received from the project stakeholders.

  • Focus Group

It is used to get a specific set of stakeholders’ requirements. For instance, you can organize a meeting with executive directors in your company to get their requirements first, and then organize a separate meeting with the functional managers to get their requirements.

  • Facilitated Workshops

In facilitated workshops, stakeholders with different perspectives are brought together. Let’s consider that you will manage a software project. You can bring analysts, software developers, test engineers, operation team, and customer together. Each group of project stakeholders will look to the project from their perspective and express their requirements. For instance, operation team will consider operational aspects, the customer will express business requirements, software developers will state the technical requirements.

  • Brainstorming

It is actually a Group Think. Several people come together to list requirements of a project. And during the meeting, new ideas are generated from existing ideas. This helps to identify new requirements.

  • Nominal Group Technique

This is actually a collect requirements process technique to prioritize ideas rather than generating new requirements. In nominal group technique, meeting participants rank the most successful ideas. This helps to focus on more valuable or prioritized ideas first in generating project requirements. Nominal group technique is usually used in brainstorming meetings. Because there will be several ideas coming from several stakeholders. If these are not ranked, focusing the stakeholders on a narrower topic and finalizing requirements will be tough.

  • Mind Mapping

This collect requirements process technique is actually a diagram of ideas or notes to help generate, classify, or record information. Ideas or parts of a project are drawn on the table, and new ideas or parts that can be in the project are generated. For an example, an airplane will consist of parts such as wings, cockpit area, tail, and passenger cabin. And when thinking about what can be in the passenger area, we can list toilets, seats, serving kitchen area etc.

  • Affinity Diagrams

Ideas generated from any other requirements gathering techniques are sorted into groups by similarities. For instance, requirements for cockpit area, requirements about passenger area, requirements about tails etc. can be grouped. Affinity Diagrams collect requirements process technique helps to see additional scope or risks. Because similar requirements will be seen together under the same group which will ease to see if there will be any more requirements or if there are any further risks regarding a group of requirements.

  • Questionnaires and Surveys

It is used for large groups where there are several stakeholders that you have to collect their requirements. Let’s consider that you have more than 200 stakeholders in a project that you need to contact and collect their requirements. Organizing a meeting or interviewing one-by-one will take a long time to finalize requirements. In this case, to prepare a questionnaire and survey and to collect requirements of several stakeholders will be easier with this technique.

  • Observation

A potential user of the product is watched to identify requirements. For instance, in order to determine the user experience or most used features of an e-commerce shopping website, a consumer can be observed. Based on the steps that the consumer will take, project requirements can be identified or prioritized.

  • Bench-marking

A company compares its actual or planned practices, to those of comparable organizations to identify best practices. Because a company must be profitable to survive in the market. And in order to be profitable, it has to know the market dynamics, competitors in the market, its strengths and weaknesses against competitors. And projects must be initiated to take a position in the market accordingly. For instance, if Samsung benchmarks its test processes with the Apple’s, this is an example of bench-marking. Because they are both in the smartphone and tablet market and they are competitors.

 

Odoo CMS - a big picture

 

Software Requirement Engineering is the process to gather the software requirements from client, analyze and document them. The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.

Requirement Engineering ensures your software will meet the user expectations, and ending up with a high quality software. It’s a critical stage of the software process as errors at this stage will reflect later on the next stages, which definitely will cause you a higher costs. At the end of this stage, a requirements document that specifies the requirements will be produced and validated with the stockholders.

Requirement Engineering is a four step process, which includes,

  • Feasibility Study

  • Requirement Gathering

  • Software Requirement Specification

  • Software Requirement Validation

Feasibility study

When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as,

  • usability

  • maintainability

  • productivity

  • integration ability

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken. When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from various stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.

SRS should come up with following features:

  • User Requirements are expressed in natural language.

Technical requirements are expressed in structured language, which is used inside the organization.

  • Design description should be written in Pseudo-code.

Format of Forms and GUI screen prints.

  • Conditional and mathematical notations for DFDs etc.


Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions:

  • If they can be practically implemented

  • If they are valid and as per functionality and domain of software

  • If there are any ambiguities

  • If they are complete