Characteristics of Requirements - Software Requirement Engineering.pptx

The slides offer a comprehensive view of software requirements engineering, stressing its pivotal role in software development. They delve into the crucial attributes defining successful requirements, including completeness, consistency, and feasibility. The presentation underscores how requirements guide system design and development from start to finish. It emphasizes the necessity of clear, verifiable requirements to align with stakeholder expectations. Ultimately, the slides succinctly encapsulate the principles and methodologies of software requirement engineering.

1. Characteristics of Requirements Software Requirement Engineering Prepared by Muhammad Saad B.S Software Engineering (PUCIT)

2. Characteristics of Good Requirements Bad requirements have been one of the top reasons for most of the projects, which fail and the rate of failure is pretty high in the IT industry. So I thought to highlight key aspects of the software requirements, which make requirements good and worthy. Any good requirement should have these 6 characteristics: Complete Consistent Feasible Modifiable Unambiguous Testable

3. Complete The requirements must be complete, what is the meaning of completeness? It means that all the required information to implement ( read  Code) the requirement. There is no need to assume anything in order to implement the same. One of the important aspects of completeness is to also have measuring units, if applicable. In case of an error, the system must exit gracefully. A complete requirement would be as follows: In case of an error, the system must show an error page to the users with the following message: Oops! We have encountered some error and working on it. In the while you can go to the home page and try other options or write to us about what were you doing, so that we can help. Our email id is [email protected]

4. Consistent Consistency is an important aspect of requirements. It means that all inputs to any process, must be processed similarly. It should not happen that processes produce different outputs for inputs coming from different sources. Consistent requirements also mean that you will not find a contradicting information in the SRS document. Let’s look at these requirements: Req1:  The invoices will be generated and sent automatically based on the milestones achieved with a copy to the accounts department Req2:  The accounts department will generate the invoice based on milestones achieved and will send it to the customer. The requirements mentioned above are not consistent as they are presenting contradictory information.

5. Feasible This is one of the crucial part of requirements capturing. All the requirements included in the SRS must be feasible to implement. A requirement to be feasible must be: Implementable within the given time frame and budget Implementable using the existing and chosen technology platform A feature, which will be used by the end users Let’s look at some of the requirements below: 1. The developed software must be reliable and should not crash. 2. The developed software must be free of defects. Both the above requirements are not feasible. There is no software which is free of defects

6. Modifiable Requirements are never static and don’t stop coming after the SRS document is signed off.  We can’t expect the customers to stop altering the requirements or adding new requirements as we also need to look at business needs. So the best way to manage the requirements is to manage these changes. In order to do so, we must have an SRS, which clearly identifies each and every requirement in a systematic manner. In case of  any changes, the specific requirements and the dependent ones can be modified accordingly without impact the others.

7. Unambiguous Unambiguous means a single interpretation. If a requirement is defined in such a manner that it can only be interpreted in one way, it means that the requirement is unambiguous. All subjective words or statements must be eliminated from the requirements. Let’s look at this requirement: All the screens in the system must load quickly. Do you think, this statement is clear? Certainly not. Nothing can be understood from the word “quickly”. It must specify clearly what is the meaning of “quickly”. A better version of this requirement would be: All the screens in the system must load within 8 seconds.

8. Testable A testable requirement can be defined as a requirement, which can be tested and validated using any of the following methods: Inspection Walkthrough Demonstration Testing In this manner, it is possible to ensure that the requirement has been implemented correctly. Let’s take an example and examine if it is testable: The system must be user-friendly. If this is allowed to be part of the final SRS document, how will you test it once the software is developed and is ready to be delivered for the UAT. It is not testable. So a better example would be: The user interface should be menu driven on the top of the website along with site index. A tool tip for all the text boxes must be provided.