REQUIREMENTS ENGINEERING
1.1.Introduction to requirement engineering
Requirements engineering (RE) refers to the process of formulating, documenting and maintaining software requirements. In the waterfall model, requirements engineering is presented as the first phase of the development process. Later software development methods, including the Rational Unified Process, Extreme Programming and Scrum assume that requirements engineering continues through the lifetime of a system. There are two types of software requirements.
1.1.1. Types of requirement
Functional requirements
In software engineering, a functional requirement defines a set of functions a software system can perform. A function is described as a set of inputs, the behavior, and outputs . Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that defines what a system is supposed to accomplish. Behavioral requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements are supported by non-functional requirements, which impose constraints on the design or implementation. In some cases a requirements analyst generates use cases after gathering and validating a set of functional requirements. The hierarchy of functional requirements is: user/stakeholder request → feature → use case → business rule. Each use case illustrates behavioral scenarios through one or more functional requirements.
Nonfunctional requirement
In requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. The plan for implementing non-functional requirements details in the system architecture. Nonfunctional requirement states the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. Examples include: Reliability, Testability, maintainability, Availability. They are also known as characteristics, constraints.
1.1.2. Requirements engineering activities
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization involved. These activities may include:
1.1.2.1. Requirements inception
1.1.2.2. Requirements gathering
Requirements gathering is the act of identifying requirements for a software project. To develop quality software, quality requirements are necessary. A formal inspection of the requirement gathered by project stakeholders who represent different perspectives is one way to determine whether each requirement has desired attributes [10]. Another powerful quality technique is to write test cases against the requirements before coding starts. Test cases crystallize view of the product’s behavior as specified in the requirements and can reveal fuzziness, omissions, and ambiguities in the gathered requirement. A good requirement has important qualities which every developer has to pay attention to during software analysis. The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed.
1.1.2.3.Requirements analysis and negotiation
Requirements analysis and negotiation involves checking requirements and resolving stakeholder conflicts. Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements. Requirements analysis is critical to the success of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
1.1.2.4. Requirements specification
The software requirement specification is the act of documenting the requirements in a requirements document. A Software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Nonfunctional requirements impose constraints on the design or implementation. The software requirements specification document enlists all necessary requirements that are required for the project development. To derive the requirements it needed to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with the project team and customer. The SRS may be one of a contract deliverable Data Item Descriptions or have another form of organizationally-mandated content. An example organization of an SRS is as follows:
1. Introduction
· Purpose
· Definitions
· System overview
· References
2. Overall description
· Product perspective
· System Interfaces
· User Interfaces
· Hardware interfaces
· Software interfaces
· Communication Interfaces
· Memory Constraints
· Operations
· Site Adaptation Requirements
· Product functions
· User characteristics
· Constraints, assumptions and dependencies
3. Specific requirements
· External interface requirements
· Functional requirements
· Performance requirements
· Design constraints
· Standards Compliance
1.1.2.4.1. Goals of good software requirement specification
For quality software development, it is important to have a good requirement specification. A well-designed, well-written SRS accomplishes four major goals:
§ It provides feedback to the customer. An SRS is the customer’s assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on.
§ It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.
§ It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also
§ It serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.
Software requirements specifications are typically developed during the first stages of ”Requirements Development,” which is the initial product development phase in which information is gathered about what requirements are needed–and not. This information-gathering stage can include on-site visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client’s current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed.
1.1.2.4.2. Information contained in the SRS
SRS development is a collaborative effort for a particular project. It is done by a team and many important areas of software development will be included. Many standards organizations have identified nine topics that must be addressed when designing and writing an SRS. These topics are:
1. Interfaces
2. Functional Capabilities
3. Performance Levels
4. Data Structures/Elements
5. Safety
6. Reliability
7. Security/Privacy
8. Quality
9. Constraints and Limitations
1.1.2.5. Requirement modeling
Requirement modeling is the act of deriving models of the system, often using a notation such as the Unified Modeling Language.The requirements model is the first technical representation of a system. The requirements modeling process uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. Software engineers build requirements models using requirements elicited from customers. Building analysis models help to make it easier to uncover requirement inconsistencies and omissions. Requirements modeling work products must be reviewed for completeness, correctness, and consistency. There are many methods that can be used to model the requirement. These methods are:
Scenario-based modeling
This modeling method shows how the user interacts with the system under a specified condition. This is done using the UML activity diagram and use case. UML requirements modeling begins with the creation of scenarios in the form of use cases, activity diagrams, and swim lane diagrams.
Developing Use Cases
The use cases capture the interactions between actors and the system. It begins by listing the activities performed by a single actor to accomplish a single function. This is continued until all the process for each actor and each system function are exhausted. Normally, the use-cases are written first in narrative form and then mapped to a template if more formality is required. Each primary scenario is reviewed and refined to see if alternative interactions are possible. It finally represented using UML use case diagrams.
Use case exceptions
It is necessary that the situations that cause the system to exhibit unusual behavior be described. This is always done using brainstorming on other to derive a reasonably complete set of exceptions for each use case. Handling exceptions may require the creation of additional use Cases.
UML Activity Diagrams
The UML activity diagram Supplements use-case by providing graphical representation of the interaction flow within a specific scenario or use case. Similar to flow chart, it has rounded rectangles used to represent functions, diamonds used to represent decision points, labeled arrows represent the system flow and Solid horizontal lines indicate parallel activities.
UML Swimlane Diagrams
The Swimlane Diagrams are a variation of activity diagrams used to show the flow of activities in use case as well as indicating which actor has responsibility for activity rectangle actions.The responsibilities are represented by parallel line segments that divide the diagram vertically headed by the responsible actor.