UNIT 2

 Software Requirements

Q1) What is Requirement Engineering? Explain its types?

A1)

Requirement Engineering is the disciplined application of proven principles, methods, tools, and notations to describe a proposed system’s intended behaviour and its associated constraints. SRS may act as a contract between developer and customer

State of practice

It is a four-step process, which includes:

Q2) Explain SRS? What are the Properties of a good SRS document?

A2)

Software requirement specification (SRS) is a formal document, which is a representation of software that enables the users to review whether it (SRS) is according to their requirements or not.it includes user requirement for a system as well as detailed specification of the system requirement. The structure of SRS differs according to the project and the requirements.

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and complete.

Structured: A well-structured document is simple to understand and modify.as user requirements are evolving continuously many revisions are need to be made to cope up with changing requirements.

Black-box view:External behaviour of the system should be defined in SRS and implementation issues are refrained from it. The SRS report should view the system to be developed as a black box and should define the externally visible behaviour of the system. Due to this the SRS report is also known as the black-box specification of a system.

Conceptual integrity: conceptual integrity should be there as response to undesired events: It should characterize acceptable responses to unwanted events. These are called system response to exceptional conditions.

Verifiable: each requirement of the system documented in the SRS document, should be clear and correct. So that it’s possible to decide whether or not requirements have been met in an implementation.

Q3) What is requirements validation?

A3)

It is desirable to detect errors in the requirements before the design and development of the software begin. To check all the issues related to requirements, requirements validation is performed.Requirements validation is similar to requirements analysis as both these processes review the gathered requirements. Requirements validation studies the ‘final draft’ of the requirements Document, while, requirements analysis studies the ‘raw requirements’ from the system users.

The output of requirement validation is a list of problems and agreed possible solutions actions of the problems. The lists of problems shows the problems encountered in the requirements document of requirement validation process. The agreed solution is a list that displays the actions to

be performed to resolve the problems.

Q4) Explain Requirements analysis in brief?

A4)

Requirements analysis is (1) the process of studying user needs to arrive at a definition of a system, hardware, or software requirements. (2) The process of studying and refining system, hardware, or software requirements.

Steps in Requirements analysis

Q5) Write a short note on Requirements Management?

A5)

Requirements management is a process of eliciting, documenting, organizing and controlling changes to the requirements. The process of requirements management begins as soon as requirements document is available, but ‘planning’ for managing the changing requirements should start during requirement elicitation process.

Q6)  Elaborate structured analysis?

A6)

Structured analysis is a top-down approach, which focuses on refining the problem with the help of functions performed in the problem domain and data produced by these functions. Generally, the structured analysis is depicted by a data flow diagram, which uses several levels to provide detailed information about the system.

The basic principles of this approach are:

• To facilitate software engineer in order to determine the information received during analysis and to organize the information to avoid complexity of the problem.

• To provide a graphical representation to develop new software or enhance the

Existing software.

Q7) What is requirement elicitation?

A7)

Requirements elicitation, also known as requirements capture and requirements acquisition, is a process of collecting information about software requirements from different individuals, such as users.

The commonly followed elicitation techniques are listed below:

• Interviews

• Scenarios

• Prototypes

• Quality function deployment (QFD)

Q8) Define feasibility and its types?

A8)

Feasibility determines or refers to the evaluation of possibility of the software process, design, procedure, or plan to know whether they can be successfully accomplished or not. To evaluate feasibility, a feasibility study is performed, which determines whether the solution considered to accomplish the requirements is practically possible or not.

Types of feasibility include:

Technical feasibility assesses the current resources (such as hardware and software) and technology, which are required to accomplish user requirements in the software within the allocated time and budget.

Operational feasibility assesses the extent to which the required software performs

Series of steps to solve business problems and user requirements.

 Economic feasibility determines whether the required software is capable of generating economic benefits for an organization or not.

Q9) Differentiate between Functional and Non-functional requirements?

A9) 

Q10) Briefly explain Data dictionary?

A10)

A data dictionary is an organized collection of information about data and their relationships, data flows, data types, data stores, processes, and so on. It also helps users to understand the data types and processes defined along with their uses.

Q11) What is the difference between SRS document and design document?

A11)

SRS Documen : Consider a flow graph given below and calculate the Cyclomatic SRS document is a contract between the development team and the customer. Once the SRS document is approved by the customer, any subsequent controversies are settled by referring the SRS document. SRS document defines the customer’s requirements in terms of Functions, performance, external interfaces and design constraints.

SRS Includes:

• Functional

• Non functional

• User

• Interface

• System

Design Document

The purpose of a design is to describe how the enhancements will be incorporated into the existing project. It should contain samples of the finished product. This could include navigational mechanism screenshots, example reports, and component diagrams.

Design Includes:

• E-R Diagrams

• Data flow diagrams

• Data Dictionary

Q12)  What do you understand by Project Planning Process?

A12)

Project planning process includes a set of interrelated activities followed in an orderly manner to implement user requirements in software. project planning process comprises of the following:

• Techniques used to perform project planning.

•  Objectives and scope of the project.

•  Effort (in time) of individuals involved in project.

• Project schedule and milestones.

• Resources required for the project.

• Risks associated with the project.

Project planning process comprises of several activities, which are essential for carrying out a project systematically. These activities refer to the series of tasks, which are performed over a period of time for developing the software. These activities include estimation of time, effort and resources required, and risks associated with the project.

Q13) Define Software Measurement and Metrics?

A13)

Software measurement is used to assess the quality of the engineered product or system for better understanding, with an intention to improve the software process on a continuous basis. Measurement helps in estimation, quality control, productivity assessment, and project control throughout a software project. Also,measurement is used by software engineers to gain insight into the design and development of the work products.

Software measurements are of two categories namely,

Direct measures include software processes like cost and effort applied and product like lines of code produced, execution speed, and other defects that have been reported.

Indirect measures include products like functionality, quality, complexity, reliability, maintainability,

software measurement is a management tool, which conducted in a set of five activities, listed below:

• Formulation: Performs measurement and develops appropriate metrics for software under consideration.

• Collection: Collects data to derive the formulated metrics.

• Analysis: Calculates metrics and use mathematical tools.

• Interpretation: Analyses the metrics to attain insight into the quality of representation.

• Feedback: Communicates recommendation derived from product metrics to the

software team.

Software Metricis “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.” The goal of software metrics is to identify and control essential parametersthat affect software development. The other objectives of using software metrics

• Measure the size of the software quantitatively.

• Assess the level of complexity involved.

• Assess the strength of the module by measuring coupling.

• Assess the testing techniques.

• Specify when to stop testing.

• Determine the date of release of the software.

• Estimate cost of resources and project schedule.

these objectives are accomplished by software metrics when applied to different projects for a long period of time to obtain indicators. Software metrics help project managers to gain an insight into the efficacy of the software process, project, and product. This is possible by collecting quality and productivity data and then analysing and comparing these data with past averages in order to know whether quality improvements have occurred or not.Also, when metrics are applied in a consistent manner, it helps in project planning and project management activity. For example, schedule based resource allocation can be effectively enhanced with the help of metrics.

Q14) Write a short note on LOC?

A14)

LOC (Lines of Code):is aSimplest and most widely used metric in which Comments and blank lines should not be counted.LOC can be defined as the number of delivered lines of code in software excluding the comments and blank lines.

Disadvantages