Unit 2
Software Requirements Engineering and Analysis
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 modeling activity. It needs to be customized to the requirements of the process, the project, the product, and the people doing the job.
Software Requirements are a set of conditions or a capability possessed by software or system components 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 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 fulfills 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.
The software can be defined as a collection of programs, documentation, and operating procedures. Institute of Electrical and Electronics Engineers (IEEE) defines software as “a collection of computer programs, procedures, rules, and associated documentation and data”.
It contains seven different activities -
Key takeaway :
- The process of identifying, recording, and preserving the specifications is Requirement Engineering.
- It is a mechanism in which the system collects and determines the service delivered.
- A method is an ordered series of operations that transforms inputs into outputs.
- Descriptions of processes encapsulate information and allow reuse of it.
The engineering of specifications is simply a matter of having constructive discussions with colleagues who are well-known team members. The truth, however, is sometimes very different.
The customer or end-user may be located in another city or country, may have only an unclear understanding of what is needed, may have conflicting opinions on the system to be installed, may have limited technical expertise, and may have limited time to connect with the requirement engineering.
Here are the steps needed to create the basis for an understanding of software requirements - to get the project started to keep it going forward towards a successful solution.
Sommerville and Sawyer describe a stakeholder as “anyone who benefits directly or indirectly 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.
As there are many distinct stakeholders, the system's specifications can be discussed from many different points of view.
Each of these voters will contribute data to the process of demand engineering. As data from different points of view is gathered, emerging demand can be inconsistent or may conflict with one another.
You can have five separate opinions on the correct set of specifications if five stakeholders are involved in a software project. Customers have to work together and with software engineering experts if it is to result in an effective system.
The role of a requirements engineer is to define areas of commonality and common areas of disagreement or incoherence. Collaboration does not necessarily indicate that committee specifications are specified. Stakeholders collaborate in many instances by giving their view of requirements, but a strong "project champion" will make the ultimate decision about which requirements cut.
Questions posed at the start of the project should be "free of context." The consumer and other stakeholders, the overall project priorities and benefits, are the subject of the first collection of context-free questions.
May you enquire:
These questions help to recognize all stakeholders that are involved in designing the program. The questions often describe the observable advantage of good implementation and potential alternatives to the creation of custom software.
The next sequence of questions helps you to have a deeper understanding of the issue and allows the client to share his or her views on a solution:
The final sequence of questions focuses on the efficacy of the very activity of communication.
Such questions will help "break the ice" and facilitate the contact required for successful elicitation.
Key takeaway :
- Each stakeholder has a different perspective of the scheme, achieves various advantages and, if the implementation effort should fail, is exposed to different risks.
- The role of a requirements engineer is to define areas of commonality and common areas of disagreement or incoherence.
- All stakeholder information should be classified in a way that will enable decision-makers to select an internally consistent set of system specifications.
The elicitation of specifications incorporates elements of issue solving, elaboration, negotiation, and specification.
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 are proposed, but informal enough to facilitate the free flow of ideas.
● The meeting is controlled by a "facilitator".
● A "mechanism of the 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 cannot be resolved during the meeting. For these suggestions to be acted on later, a problem list is kept.
When parameters are collected, an overall view of device functions and functions are beginning to materialize. 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 practices.
Developers and users may build a set of scenarios to achieve this, which define a thread of use for the framework to be designed.
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.
A use case is a list of behaviour or event steps in software and systems engineering that usually describe the interactions between a role (known as an actor in the Unified Modeling Language (UML)) and a system to achieve a goal. A human or other external systems may be the actor.
Use cases are used at a higher level in systems engineering than in software engineering, often representing missions or stakeholder objectives.
Use cases are a tool to capture, model, and define a system's requirements.[10] A use case refers to a collection of actions that can be performed by the system in interaction with its actors, generating an observable outcome that contributes to its objectives. The role of human users or other systems in interaction is portrayed by actors.
In the requirement review, the use case is named after the particular user-goal it serves as its primary actor when defined. A textual summary or supplementary graphical models explaining the general sequence of activities and occurrences, as well as variants such as special circumstances, anomalies, or situations of mistake, provide more specifics of the case.
Characteristics linked to instances of use are:
● Organizing practical needs
● Modeling the purposes of user experiences in the system
● Recording scenarios from cause incidents to ultimate objectives
● Describing the fundamental course of actions and the particular flow of events
● Allowing a user to control another event's features
In designing use cases, the steps are:
● Identify the system's users
● Structure of the use cases
● Review and validate the users
● Build a user profile for each group of users. This includes all of the positions played by system-relevant users.
Key takeaway :
- A use case is a method to describe the user interaction required.
- In the distinct phases of the Software Development Life Cycle, use case plays an important role.
- The Use Case relies on 'User Behavior' and' Device Response 'for User Actions.
Both individuals who have engaged in the elicitation of specifications are evaluating each of these job items. As you know more about the structure to be developed, the paradigm shifts dynamically, and other stakeholders understand more about what they want. For that reason, at any given time, the analysis model is a snapshot of requirements.
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 1: Activity diagram for Eliciting
Class-based elements – Each scenario of use involves a selection of artifacts that are manipulated as an actor communicates with the device. Such artifacts are grouped into groups, a group of items with similar characteristics and common behaviours.
Fig 2: 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 modeling 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 3: 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).
Key takeaway :
- The first component of the model that is developed is mostly scenario-based elements of the requirements mode
- Each scenario of use involves a selection of artifacts that are manipulated as an actor communicates with the device.
- In a variety of forms, the machine receives input, applies functions to transform it, and generates output in a variety of forms.
- model specifications must have modeling components that reflect behaviour.
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.
It is checked for inconsistency, omissions, and uncertainty as each aspect of the requirements model is developed. Stakeholders prioritize the specifications represented by the model and organize 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 criterion restricted and unequivocal?
● Is there attribution to each requirement? That is, for each criterion, is a source noted?
● Do other conditions clash with any specifications?
● In the technical setting that will house the device or product, is each requirement achievable?
● Is each criterion, once enforced, testable?
● Does the model of requirements properly represent the system's knowledge, purpose, and actions to be built?
● Has the model of specifications been "partitioned" in a way that gradually reveals more accurate system information?
● Have patterns of requirements been used to simplify the model of requirements?
● Have all the trends been validated properly? Are these trends compliant with client demands?
Key takeaway :
- 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.
- It is checked for inconsistency, omissions, and uncertainty as each aspect of the requirements model is developed
References:
2. S K Chang, ―Handbook of Software Engineering and Knowledge Engineering‖, World Scientific, Vol I, II, ISBN: 978-981-02-4973-1
