Documente Academic
Documente Profesional
Documente Cultură
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. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains non-functional requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). Software Requirements is a sub-field of Software engineering that deals with the elicitation, analysis, specification, and validation of requirements for software. The software requirement specification (SRS) document enlists all necessary requirements for project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with project team and the customer. A general organization of an SRS is as follows Introduction Purpose Scope Definitions System Overview References
Overall Description Product Perspective Product Functions User Characteristics Constraints, Assumptions and Dependencies
by our clients. Essential to having a great Software Specification is having a great System Specification. The equivalent IEEE standard for that is IEEE STD 1233-1998. However, for most purposes in smaller systems, the same templates can be used for both.
hardware, other hardware, and other software? c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.? d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations? e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?
marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS. Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of my favorites is - "The system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds." Modifiable - Having the same requirement in more than one place may not be wrong but tends to make the document not maintainable. Traceable - Often, this is not important in a non-politicized environment. However, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. Why do we need this requirement?
One job of the System specification is to define the full functionality of the system. In many systems we work on, some functionality is performed in hardware and some in software. It is the job of the System specification to define the full functionality and like the performance requirements, to set in motion the trade-offs and preliminary design studies to allocate these functions to the different disciplines (mechanical, electrical,
software). Another function of the System specification is to specify performance. For example, if the System is required to move a mechanism to a particular position accurate to a repeatability of 1 millimeter, that is a Systems requirement. Some portion of that repeatability specification will belong to the mechanical hardware, some to the servo amplifier and electronics and some to the software. It is the job of the System specification to provide that requirement and to set in motion the partitioning between mechanical hardware, electronics, and software. Very often the System specification will leave this partitioning until later when you learn more about the system and certain factors are traded off (For example, if we do this in software we would need to run the processor clock at 40 mHz. However, if we did this function in hardware, we could run the processor clock at 12 mHz). [This implies that a certain level of research or even prototyping and benchmarking needs to be done to create a System spec. I think it is useful to say that explicitly.] However, for all practical purposes, most of the systems we are involved with in small to medium size companies, combine the software and the systems documents. This is done primarily because most of the complexity is in the software. When the hardware is used to meet a functional requirement, it often is something that the software wants to be well documented. Very often, the software is called upon to meet the system requirement with the hardware you have. Very often, there is not a systems department to drive the project and the software engineers become the systems engineers. For small projects, this is workable even if not ideal. In this case, the specification should make clear which requirements are software, which are hardware, and which are mechanical.
Electrical Design. Systems/Software Creates a Software Specification and gives it to Software. It should define everything Software needs to develop the software. Thus, the SRS should define everything explicitly or (preferably) by reference that software needs to develop the software. References should include the version number of the target document. Also, consider using master document tools which allow you to include other documents and easily access the full requirements.
Is this do-able? Wont we miss our deadlines if we take the time to do this?
This is a great question. There is no question that there is balance in this process. We have seen companies and individuals go overboard on documenting software that doesnt need to be documented, such as a temporary utility. We have also seen customers kill good products by spending too much time specifying it. However, the bigger problem is at the other end of the spectrum. We have found that taking the time up front pays dividends down stream. If you dont have time to specify it up front, you probably dont have the time to do the project. Here are some of our guidelines: Spend time specifying and documenting well software that you plan to keep. Keep documentation to a minimum when the software will only be used for a short time or has a limited number of users. Have separate individuals write the specifications (not the individual who will write the code). The person to write the specification should have good communication skills. Pretty diagrams can help but often tables and charts are easier to maintain and can communicate the same requirements. Take your time with complicated requirements. Vagueness in those areas will come back to bite you later. Conversely, watch out for over-documenting those functions that are well understood by many people but for which you can create some great requirements. Keep the SRS up to date as you make changes. Approximately 20-25% of the project time should be allocated to requirements
definition. Keep 5% of the project time for updating the requirements after the design has begun. Test the requirements document by using it as the basis for writing the test plan.
Do you know Most of the bugs in software are due to incomplete or inaccurate functional requirements? The software code, doesnt matter how well its written, cant do anything if there are ambiguities in requirements. Its better to catch the requirement ambiguities and fix them in early development life cycle. Cost of fixing the bug after completion of development or product release is too high. So its important to have requirement analysis and catch these incorrect requirements before design specifications and project implementation phases of SDLC. How to measure functional software requirement specification (SRS) documents? Well, we need to define some standard tests to measure the requirements. Once each requirement is passed through these tests you can evaluate and freeze the functional requirements. Lets take an example. You are working on a web based application. Requirement is as follows: Web application should be able to serve the user queries as early as possible How will you freeze the requirement in this case? What will be your requirement satisfaction criteria? To get the answer, ask this question to stakeholders: How much response time is ok for you? If they say, we will accept the response if its within 2 seconds, then this is your requirement measure. Freeze this requirement and carry the same procedure for next requirement. We just learned how to measure the requirements and freeze those in design, implementation and testing phases. Now lets take other example. I was working on a web based project. Client (stakeholders) specified the project requirements for initial phase of the project
development. My manager circulated all the requirements in the team for review. When we started discussion on these requirements, we were just shocked! Everyone was having his or her own conception about the requirements. We found lot of ambiguities in the terms specified in requirement documents, which later on sent to client for review/clarification. Client used many ambiguous terms, which were having many different meanings, making it difficult to analyze the exact meaning. The next version of the requirement doc from client was clear enough to freeze for design phase. From this example we learned Requirements should be clear and consistent Next criteria for testing the requirements specification is Discover missing requirements Many times project designers dont get clear idea about specific modules and they simply assume some requirements while design phase. Any requirement should not be based on assumptions. Requirements should be complete, covering each and every aspect of the system under development. Specifications should state both type of requirements i.e. what system should do and what should not. Generally I use my own method to uncover the unspecified requirements. When I read the software requirements specification document (SRS), I note down my own understanding of the requirements that are specified, plus other requirements SRS document should supposed to cover. This helps me to ask the questions about unspecified requirements making it clearer. For checking the requirements completeness, divide requirements in three sections, Must implement requirements, requirements those are not specified but are assumed and third type is imagination type of requirements. Check if all type of requirements are addressed before software design phase. Check if the requirements are related to the project goal. Some times stakeholders have their own expertise, which they expect to come in system under development. They dont think if that requirement is relevant to project in hand. Make sure to identify such requirements. Try to avoid the irrelevant requirements in first phase of the project development cycle. If not possible ask the questions to stakeholders: why you want to implement this specific requirement? This will describe the particular requirement in detail making it easier for designing the system considering the future scope. But how to decide the requirements are relevant or not? Simple answer: Set the project goal and ask this question: If not implementing this requirement will cause any problem achieving our specified goal? If not, then this is irrelevant requirement. Ask the stakeholders if they really want to implement these types of requirements.
In short requirements specification (SRS) doc should address following: Project functionality (What should be done and what should not) Software, Hardware interfaces and user interface System Correctness, Security and performance criteria Implementation issues (risks) if any Conclusion: I have covered all aspects of requirement measurement. To be specific about requirements, I will summarize requirement testing in one sentence: Requirements should be clear and specific with no uncertainty, requirements should be measurable in terms of specific values, requirements should be testable having some evaluation criteria for each requirement, and requirements should be complete, without any contradictions Testing should start at requirement phase to avoid further requirement related bugs. Communicate more and more with your stakeholder to clarify all the requirements before starting project design and implementation.