Unit - 2
Software Requirements Engineering and Analysis
Q.1) What is the requirement engineering? Listed the seven distinct tasks?
Sol : Requirement Engineering -
Requirement engineering is the broad spectrum (variety , range) of tasks and techniques that lead to an understanding of requirements.
In other words, RE(requirement engineering) refers to the mechanism in which specifications are specified, recorded and preserved.
A major software engineering operation is from a requirement engineering that starts during the communication activity and continues into the modelling activity. It needs to be customised to the requirements of the process, the project, the product and the people doing the job.
Software Requirements are set of conditions or a capability possessed by software
or system component to solve a real world problem. The problems can be to
automate a part of a system to correct shortcomings of an existing system, to control
a device, and so on. IEEE defines a requirement as:
“A condition or capability needed by a user to solve a problem or achieve an
objective” or “ The capability possessed by a system to satisfy a contract, standard,
specification, or other formally imposed documents”.
When users request for software, they possess an approximation of what the new
system should be capable of doing. Requirements differ from one user to another
user and from one business process to another business process. Reliability means
Operational reliability.
It contains seven different activities -
Q.2) What do you mean by Eliciting requirements ?
Sol : Eliciting Requirements - The elicitation of specifications incorporates elements of issue solving, elaboration, negotiation, and specification.
Collaborative Requirements Gathering -
Many different approaches to collecting collaborative criteria have been suggested.
● Both software developers and other stakeholders conduct and attend meetings.
● Laws are formed for training and participation.
● An agenda that is structured enough to address all important points is proposed, but informal enough to facilitate the free flow of ideas.
● The meeting is controlled by a "facilitator".
● A "mechanism of definition" (which can be work papers, flip charts, etc.) is used.
The objective is to define the problem, propose elements of the solution, negotiate various approaches and specify a preliminary set of criteria for the solution in an environment conducive to the achievement of the objective.
Each participant is asked to make a list of objects that are part of the environment that surrounds the system, other objects that are to be generated by the system, and objects that are used by the system to perform its functions, while reviewing the product request in the days before the meeting.
For review, the mini-specs are presented to all stakeholders. There are additions, deletions, and further elaboration.In certain instances, new objects will be discovered by the growth of mini-specs, Services, limits, or performance parameters that will be applied to the initial lists.
The team can pose a problem during all the discussions that can not be resolved during the meeting. In order for these suggestions to be acted on later, a problem list is kept.
Usage Scenarios -
When parameters are collected, an overall view of device functions And functions are beginning to materialise. However, once you understand how these functions and features would be used by various groups of end users, it is hard to step into more advanced software engineering practises.
Developers and users may build a set of scenarios to achieve this, which define a thread of use for the framework to be designed.
Elicitation Work Products -
The task products produced as a result of the elicitation of requirements will differ depending on the size of the system or product to be designed. For most systems, the goods for the task include
● A need and feasibility statement.
● A restricted declaration of scope for the device or service.
● A registry of clients, consumers, and other stakeholders that have been interested in the elicitation of specifications.
● A summary of the technological environment of the device.
● A set of criteria and the domain limitations that apply to each.
● A compilation of use scenarios that provide insight into the use under various operating conditions of the device or product.
● To better define requirements, all prototypes were made.
Q.3) Elaborate on elements of the requirements model ?
Sol : Elements of the requirements model :-
For a computer-based system, there are several different ways of looking at the specifications. Different representation types compel you to consider criteria from multiple points of view, an approach that is more likely to expose omissions, contradictions, and uncertainty.
Scenario-based elements -From the user's perspective, the system is represented using a Scenario-based methodology. Basic use cases and their accompanying use-case diagrams, for instance, develop into more elaborate use cases based on models.
The first component of the model that is developed is mostly scenario-based elements of the requirements model. Three stages of elaboration are shown, resulting in a representation based on scenarios.
Fig : Activity diagram for Eliciting
Class-based elements - Each scenario of use involves a selection of artefacts that are manipulated as an actor communicates with the device. Such artefacts are grouped into groups, a group of items with similar characteristics and common behaviours.
Fig : class diagram for sensor
Behavioral elements - A computer-based system's actions can have a profound impact on the chosen specification and the approach to implementation that is implemented. Therefore, model specifications must have modelling components that reflect behaviour.
One way to describe a system's actions by describing its states and the events that cause the system to change its state is the state diagram. Any externally measurable mode of action is a state.
Furthermore, as a result of a specific incident, the state diagram shows actions taken.
Fig : State diagram notation
Flow-oriented elements - As knowledge flows through a computer-based system, it converts . In a variety of forms, the machine receives input, applies functions to transform it, and generates output in a variety of forms .
A control signal transmitted by a transducer can be the input, a number series typed by a human operator, an information packet transmitted over a network connection, or a voluminous data file retrieved from secondary storage.
A single logical comparison, a complex numerical algorithm, or an expert system's rule-inference approach can comprise the transform(s).
Q.4) What do you mean by Negotiating Requirements ?
Sol : Negotiating Requirements :-
In an ideal engineering background for specifications, customer requirements are determined in sufficient detail by the initiation, elicitation, and elaboration tasks to proceed to subsequent software engineering activities. You may have one or more stakeholders to enter into a negotiation.
In certain situations, stakeholders are asked to balance cost and time-to-market functionality, performance and other product or device characteristics.
The goal of this negotiation is to create a project plan that meets the needs of stakeholders while representing the real-world constraints that have been imposed on the software team (e.g. time, personnel, budget).
The best deals pursue a "win-win" outcome. That is, by having the method or product that meets most of their needs, stakeholders win and you win by working towards practical and achievable budgets and deadlines.
Boehm [Boe98] defines a set of negotiation activities at the beginning of each software process iteration .
The following activities are described instead of a single customer contact activity:
● Identification of the main stakeholders of the device or subsystem.
● Determination of "win terms" for the stakeholders.
● Negotiation of winning conditions for stakeholders to reconcile them to a set of win-win conditions for everyone concerned.
Q.5) Define usage scenarios and elicitation work products ?
Sol : Usage Scenarios :
When parameters are collected, an overall view of device functions
And functions are beginning to materialise. However, once you understand how these functions and features would be used by various groups of end users, it is hard to step into more advanced software engineering practises.
Developers and users may build a set of scenarios to achieve this, which define a thread of use for the framework to be designed.
Elicitation Work Products -
The task products produced as a result of the elicitation of requirements will differ depending on the size of the system or product to be designed. For most systems, the goods for the task include
● A need and feasibility statement.
● A restricted declaration of scope for the device or service.
● A registry of clients, consumers, and other stakeholders that have been interested in the elicitation of specifications.
● A summary of the technological environment of the device.
● A set of criteria and the domain limitations that apply to each.
● A compilation of use scenarios that provide insight into the use under various operating conditions of the device or product.
● To better define requirements, all prototypes were made.
Q.6) What do you mean by validating requirements?
Sol : Validating requirements :-
It is checked for inconsistency, omissions, and uncertainty as each aspect of the requirements model is developed. Stakeholders prioritise the specifications represented by the model and organise them into requirement packages that will be introduced as software increments.
The following issues are answered by an analysis of the criteria model:
● Is each condition compatible with the overall system/product targets?
● At the proper level of abstraction, have all specifications been specified? That is to say, do some specifications include a degree of technical detail that at this point is inappropriate?
● Is the requirement really important or does it reflect an add-on role that may not be relevant to the system's objective?
● Is each criteria restricted and unequivocal?
● Is there attribution to each requirement? That is, for each criterion, is a source noted?
Q.7) What do you mean by Identifying Stakeholders ?
Sol : Sommer ville and Sawyer describe a stakeholder as “ anyone who benefits in a direct or indirect way from the system which is being developed” .
Like - Software engineering, Support and Maintenance engineers, business operation managers, Product managers, Marketing people, Internal and External customers and others .
Each stakeholder has a different perspective of the scheme, achieves various advantages and, if the implementation effort should fail, is exposed to different risks.
Q.8) Define the software requirements ?
Sol : Software requirement -
Software Requirements are set of conditions or a capability possessed by software
or system component to solve a real world problem. The problems can be to
automate a part of a system to correct shortcomings of an existing system, to control
a device, and so on. IEEE defines a requirement as:
“A condition or capability needed by a user to solve a problem or achieve an
objective” or “ The capability possessed by a system to satisfy a contract, standard,
specification, or other formally imposed documents”.
When users request for software, they possess an approximation of what the new
system should be capable of doing. Requirements differ from one user to another
user and from one business process to another business process.
Reliability means Operational reliability. It is described as the ability of a system or component to perform its required functions under static conditions for a specific period.it can also be described as the probability that a software system fulfils its assigned task in a given environment for a predefined number of input cases, assuming that the hardware and the input are free of error.
Software can be defined as a collection of programs, documentation and operating
procedures. Institute of Electrical and Electronic Engineers (IEEE) defines software
as “a collection of computer programs, procedures, rules, and associated
documentation and data”.
Q.9) What are the features of software requirements?
Sol : Features of software:
● Functionality: Refers to the degree of performance of the software against its intended purpose.
● Reliability: Refers to the ability of software to perform a required function under given conditions for a specified period.
● Usability: Refers the degree to which software is easy to use.
● Efficiency: Refers to the ability of software to use system resource in the most effective and efficient manner. • Maintainability: Refers to the ease with which a software system can be modified to add capabilities, improve system performance, or correct errors.
● Portability: Refers to the ease with which software developers can transfer software from one platform to another, without (or with minimum) changes
● Robustness: it is the ability of a software to handle an unexpected errors and faults with ease.
● Integrity: integrity in software is the better quality of software’s source code.
“Gathering software requirements is the foundation of the entire software
development project. Hence they must be clear, correct and well-defined.”
Software Requirements Characteristics:
Q.10) What are the types of software requirements ?
Sol : Type of requirements:
Examples: Search option given to user to search from various invoice User should be able to mail any report to management Users groups can be given separate rights
Software should comply with business rules and administrative functions.
It include –
● Security
● Logging
● Storage
● Configuration
● Performance
● Cost
● Interoperability
● Flexibility
● Disaster recovery
● Accessibility
