Skip to main content

Software Requirements In Software Engineering | VCMIT



Software Requirements


The software requirements are description of features and functionalities of the target system. Requirements convey 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.

Requirement Engineering

The process to gather the software requirements from client, analyze and document them is known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –
  • Feasibility Study
  • Requirement Gathering
  • Software Requirement Specification
  • Software Requirement Validation
Let us see the process briefly -

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 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
  • If they can be demonstrated


Comments

Popular posts from this blog

Create House Like Structure Perform Operations Program In C | VCMIT

Program to create a house like figure and perform the following operations.  Scaling about the origin followed by translation.  Scaling with reference to an arbitrary point. Reflect about the line y = mx + c. INPUT #include <stdio.h> #include <graphics.h> #include <stdlib.h> #include <math.h> #include <conio.h> void reset (int h[][2]) { int val[9][2] = { { 50, 50 },{ 75, 50 },{ 75, 75 },{ 100, 75 }, { 100, 50 },{ 125, 50 },{ 125, 100 },{ 87, 125 },{ 50, 100 } }; int i; for (i=0; i<9; i++) { h[i][0] = val[i][0]-50; h[i][1] = val[i][1]-50; } } void draw (int h[][2]) { int i; setlinestyle (DOTTED_LINE, 0, 1); line (320, 0, 320, 480); line (0, 240, 640, 240); setlinestyle (SOLID_LINE, 0, 1); for (i=0; i<8; i++) line (320+h[i][0], 240-h[i][1], 320+h[i+1][0], 240-h[i+1][1]); line (320+h[0][0], 240-h[0][1], 320+h[8][0], 240-h[8][1]); } void rotate (int h[][2], float angle) { int i; for (i=0; i<9; i++) { int xnew, ynew; xnew = h[i][0] * cos (angle) - h[i]

Software Engineering - Waterfall Model | VCMIT

Waterfall model Winston Royce introduced the Waterfall Model in 1970.This model has five phases: Requirements analysis and specification, design, implementation, and unit testing, integration and system testing, and operation and maintenance. The steps always follow in this order and do not overlap. The developer must complete every phase before the next phase begins. This model is named "Waterfall Model", because its diagrammatic representation resembles a cascade of waterfalls. 1. Requirements analysis and specification phase: The aim of this phase is to understand the exact requirements of the customer and to document them properly. Both the customer and the software developer work together so as to document all the functions, performance, and interfacing requirement of the software. It describes the "what" of the system to be produced and not "how."In this phase, a large document called Software Requirement Specification (SRS) document is created whic

Software Engineering - Spiral Model | VCMIT

Spiral Model The spiral model, initially proposed by Boehm, is an evolutionary software process model that couples the iterative feature of prototyping with the controlled and systematic aspects of the linear sequential model. It implements the potential for rapid development of new versions of the software. Using the spiral model, the software is developed in a series of incremental releases. During the early iterations, the additional release may be a paper model or prototype. During later iterations, more and more complete versions of the engineered system are produced. Each cycle in the spiral is divided into four parts: Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the various alternatives that are possible for achieving the targets, and the constraints that exists. Risk Assessment and reduction: The next phase in the cycle is to calculate these various alternatives based on the goals and constraints. The focus of evaluation