Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Engineering - chp2- requirements specification

Requirements Specification

  • Be the first to comment

Software Engineering - chp2- requirements specification

  1. 1. MedTech Chapter 2 – RequirementsSpecification How to write a requirements specification Dr. Lilia SFAXI Slide 1 MedTech – Mediterranean Institute of Technology Software Engineering MedTech
  2. 2. MedTech Requirements Specification… Why? 2 If you don’t know where you’re going, you will probably end up somewhere else. Laurence J. Peter
  3. 3. MedTech SRS: Software Requirements Specification • The organization’s understanding, in writing, of a customer or potential client’s system requirements and dependencies at a particular point in time, usually prior to any actual design or development work. • A two way insurance policy • Insures that both the client and the organization understand the other’s requirements from that perspective at a given time • States: • The functions and capabilities a software system must provide • The required constraints by which the system must abide • Called the “parent” document 3 Requirements Specification
  4. 4. MedTech SRS: Major Goals • Providing feedback to the customer • SRS is the customer’s assurance that the dev. organization understands his needs • SRS should be written in a natural language, in an unambiguous manner • May include charts, tables, data flow diagrams, decision tables,… • Decomposing the problem into component parts • The information is organized, borders are placed, ideas solidified • Serving as an input to the design specification • As a parent document, it comes prior to the design spec. • Must then contain sufficient details about the functional system’s requirements for the design solution to be devised • Serving as a product validation check • Is also the parent document for testing and validation strategies • Is a basis for estimating costs and schedules 4 Requirements Specification
  5. 5. MedTech SRS: Content (IEEE 830 standard) • Functionality • What is the software supposed to do? • External Interfaces • How does the software interact with people, the system’s hardware, other hardware, and other software? • Performance • What is the speed, availability, response time, recovery time of various software functions? • Attributes • What are the portability, correctness, maintainability, security, etc. considerations? • Design constraints imposed on an implementation • Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environments, etc.? Dr. Lilia SFAXI Slide 5 Requirements Specification
  6. 6. MedTech SRS: What it contains, what it doesn’t • SRS provides: • Function requirements • Non-functional requirements • SRS doesn’t provide: • Design suggestions • Possible solutions to technology or business issues 6 Requirements Specification
  7. 7. MedTech What makes an SRS a GREAT SRS? • An SRS should be: (IEEE 830 standard) • Correct, but also ever correcting • It must be corrected whenever you find incorrect things along the dev or design phases • Unambiguous • Every requirement stated therein has only one interpretation • Fix ambiguities when found, instead of spending endless time trying to avoid them • Complete • It should be all that is needed by the software designers to create the software • Consistent • Within itself and to its reference documents (no contradictions) • Ranked for importance and/or stability • Importance and stability (chances of change) for each requirement must be specified Dr. Lilia SFAXI Slide 7 Requirements Specification
  8. 8. MedTech What makes an SRS a GREAT SRS? • An SRS should be: (IEEE 830 standard) • Verifiable • “fast response” and “the system should never crash” are totally forbidden statements! • Provide quantitative requirements instead of just suppositions • Modifiable • Prefer a shared document to multiple copies • Traceable • You should document the life of a requirement and provide bi-directional traceability between the associated requirements • Helps find the origin of each requirement and track the changes that were made Dr. Lilia SFAXI Slide 8 Requirements Specification
  9. 9. MedTech Major Challenge: Requirements Gathering Dr. Lilia SFAXI Slide 9 Requirements Specification
  10. 10. MedTech Technical Writers.. • A technical writer is a professional writer who produces technical documentation that helps people understand and use a product or service • Technical Writers should be involved with SRS • And we mean.. to the whole specification writing phase! • Benefits • They can gather efficiently the information from the customer • They can better assess and plan documentation projects and meet customer document needs • They know how to determine the questions that are of concern to the user • If involved early and often in the gathering process, they can become an information resource throughout the process, rather than an information gatherer at its end Dr. Lilia SFAXI Slide 10 Requirements Specification
  11. 11. MedTech Working with Requirements.. A Lifecycle Activity! Dr. Lilia SFAXI Slide 11 Requirements Specification Requirements Capture& Definition Analysis & Design Tools Modeling Tools Simulation Tools Coding Tools Testing Tools RequirementsManagement & Traceability Tools
  12. 12. MedTech Best Practices for Writing Better Requirements 1. Use the simplest words appropriate to state a complete requirement 2. Use requirement imperatives correctly Dr. Lilia SFAXI Slide 12 Requirements Specification Imperatives:words and phrases that command the presence of some feature, function or deliverable. Listed below in decreasing order ofstrength. Shall Used todictate theprovision of afunctional capability. Must or must not Most often used to establish performancerequirementor constraints. Is required to Used asan imperativein SRS statements when written in passivevoice. Areapplicable Used toinclude, byreference, standards, or other documentation asan addition to the requirementbeing specified. Responsible for Used asan imperativein SRSs thatarewritten for systems with pre-defined architectures. Will Used tocite thingsthattheoperational or development environmentis to providetothe capability being specified. For example, Thevehicle'sexhaustsystem will power theABC widget. Should Not used often as an imperative in SRS statements; however, when used, theSRSstatement always readsweak. Avoid using Should in your SRSs.
  13. 13. MedTech Best Practices for Writing Better Requirements 3. Do not use weak phrases and subjective words • Avoid words like: adequate, appropriate, bad, better, but not limited to, easy, minimize… 4. Use continuations carefully, they make traceability difficult • Continuances: Phrases that follow an imperative and introduce the specification of requirements at a lower level. There is a correlation with the frequency of use of continuances and SRS organization and structure, up to a point. • Example: The system shall report software status to the host interface under the following conditions: • At system Initialization • When the status of an external interface has changed • When a report has been requested Ø These are actually three requirements Dr. Lilia SFAXI Slide 13 Requirements Specification
  14. 14. MedTech Best Practices for Writing Better Requirements 5. Use examples, tables, figures etc. but make sure examples and notes are clearly marked as such 6. Be consistent with names! Always call the same entity by the same name 7. If you use a TBD (to be determined) or TBR (to be resolved), have a plan. You must state who is responsible for the information, and when will it be completed 8. Make sure your requirement contains all the qualities of a good requirement (see "What makes an SRS a great SRS" above) Dr. Lilia SFAXI Slide 14 Requirements Specification
  15. 15. MedTech Best Practices for Writing Better Requirements 9. Make sure that if a requirement references another document, that it does so correctly • References must be listed in applicable document section and state what part of references applies • List all the versions of your document and the changes it applies compared to the previous version • Use a naming convention in order to apply a unique name to every document you use, for example SRS-ProjID-Version-Date.docx Dr. Lilia SFAXI Slide 15 Requirements Specification
  16. 16. MedTech Best Practices for Writing Better Requirements 10. Make sure that acronyms are used correctly • Place the acronym in the acronym list in the specification • Spell out the complete phrase followed by the acronym in parenthesis the first time it is used • The next time, you can just use the acronym 11. Overspecification leads to unfunded requirements and can add duplicate requirements • Shorten the requirements as possible Dr. Lilia SFAXI Slide 16 Requirements Specification
  17. 17. MedTech Best Practices for Writing Better Requirements 12. Use the requirement template • Define a template document for your requirements • This is the structure of a basic requirement: [Conditions] [Subject][Action][Object][Constraint] • Entities: Subject of the requirements and Object of the action • Actions: What the subject does, contains an imperative • Conditions: What must be in place in order for the action to take place • Constraints: Qualifies the action, performance • Example: • When signal x is received, the system shall set the signal x received bit within 2 seconds 13. Design for asset reuse 14. Finding the right combination of approaches for the development process • X-driven development Dr. Lilia SFAXI Slide 17 Requirements Specification
  18. 18. MedTech But also… 1. Spend time specifying and documenting well software that you plan to keep. 2. Keep documentation to a minimum when the software will only be used for a short time or has a limited number of users. 3. Have separate individuals write the specifications (not the individual who will write the code). 4. The person to write the specification should have good communication skills. 5. Take your time with complicated requirements. Vagueness in those areas will come back to bite you later. 6. Keep the SRS up to date as you make changes. 7. Approximately 20-25% of the project time should be allocated to requirements definition. 8. Keep 5% of the project time for updating the requirements after the design has begun. 9. Test the requirements document by using it as the basis for writing the test plan. Dr. Lilia SFAXI Slide 18 Requirements Specification
  19. 19. MedTech References Dr. Lilia SFAXI Slide 19 • Donn Le Vie, Jr, Writing Software Specifications • Michelle Specht, Best Practices Writing Requirements for Requirements Management, • Robert Japenga, How to write a software requirements specification