IEEE 830-1998 Software Requirements Specification PDF

SEF IEEE – Software Requirements Specification (SRS)  IEEE Software Requirements Specification About Requirements  In the last couple of lessons, we learned about  The reason(s) why we need requi...

SEF IEEE – Software Requirements Specification (SRS)  IEEE Software Requirements Specification About Requirements  In the last couple of lessons, we learned about  The reason(s) why we need requirements  Formalizing and documenting requirements  Possible ways to gather requirements  The characteristics of good requirements  In this lesson, we will  Talk more about the characteristics of requirements  How the IEEE 830-1998 Specification can help ensure that requirements are documented properly  We will start by examining …  IEEE Software Requirements Specification The Life of a Project …  The following cartoon illustrates (sadly enough) how some software projects run …  FYI … The reason that the project may be run this way is not entirely because of lack of requirements and poorly documented requirements … but these definitely contribute!  IEEE Software Requirements Specification How the Customer Explained It How the Business Analyst IEEE Software Requirements Specification Understood It  IEEE Software Requirements Specification How the Architect Designed It  IEEE Software Requirements Specification How the Developer Implemented It  IEEE Software Requirements Specification How the Business Consultant Described It  IEEE Software Requirements Specification How the Project Was Documented  IEEE Software Requirements Specification How Operations Installed the Project  IEEE Software Requirements Specification How The Customer Was Billed  IEEE Software Requirements Specification How It Was Supported  IEEE Software Requirements Specification What the Customer Really Needed What you should take away from IEEE Software Requirements Specification this …  After viewing that series of cartoon images, you should realize that it takes many people and roles to have a successful and acceptable project  In this and coming courses – you will learn about these different roles…  … and you will be given the skills to put on that role hat and do the job correctly and accurately  At this point in your training, you should realize that it is crucial to  Interact and listen to the customer – to really, truly and honestly understand and gather the requirements for what it is that they need  Precisely, accurately and completely document these customer requirements so that the project can be a success  These two initial steps set the project on a course for success! Important Concepts To take away from this lesson about: - the IEEE Specification - Requirements (in general)  IEEE Software Requirements Specification The Nature of the SRS  Thecore reasons for producing an SRS, are to address and capture certain characteristics of the system. These include:  Functionality  What is the software supposed to do?  External Interfaces  How does the software interact with people, the system's hardware, other hardware, other software and other systems?  Performance  What is the speed, availability, response time, recovery time, etc.?  System Attributes  What are the portability, correctness, maintainability, security, etc. considerations?  Design constraints  Are there any required standards in effects, implementation language, policies for database integrity, resource limits, operating environments, etc.?  IEEE Software Requirements Specification The IEEE 830-1998 Standard  The IEEE produced this standards document in the late 1990’s in order to help the blossoming software industry standardize on a format of documenting requirements for software based systems being developed  The resultant SRS has only 3 sections and each of these sections has a certain number of required sub-sections  Each of these 3 main sections have a specific purpose in the communication of system requirements  IEEE Software Requirements Specification The IEEE 830-1998 Standard (cont’d)  Section 1’s purpose is to tell the reader about the SRS …  It talks about the software system being documented - it’s purpose and scope  It also contains information to help the reader of the SRS understand the contents of the document … it includes a glossary of terms and definitions, it includes references to other important supporting documents, etc.  Section 2’s purpose is to tell the reader about the functionality, external interfaces, performance, system attributes and constraints  Section 3’s purpose is to tell the reader about the functionality, external interfaces, performance, system attributes and constraints  What?!? Section 2 and Section 3 cover the same material?!?!  The reason is that each of these sections and their content are written to address a different type of reader (target  IEEE Software Requirements Specification The IEEE 830-1998 Standard (cont’d)  Section 2’s target audience  Are those stakeholders who are non-technical  These readers need to have a complete picture and understanding of the software system – but do not need or comprehend the lower-level (technical) details  You might say that these readers only need an comprehensive overview of the system without the specific technical details  These stakeholders may often include the customer as well as management personnel … it is crucial that they understand the characteristics of the system, but do not require all of the details  Section 3’s target audience  Are those stakeholders who are technical  In order to perform their roles in the system development, these readers need to have the complete (low-level) picture and understanding of the software system  These stakeholders include the business analysts, architects, developers, testers and system maintenance team  These are the people who will be developing the system and supporting it. They need very specific, detailed information about the characteristics of the system  IEEE Software Requirements Specification About Interfaces  One of the characteristics that needs to be documented in the complete SRS are the system’s external interfaces  An interface can be defined as any outside (or external) entity that the system being documented and developed depends on in order to carry out and achieve its purpose  These external entities can include other systems, other pieces of software, special hardware components, specific communication protocols as well as the user interface (UI) of the system being developed.  Please see the descriptions of the interfaces listed in Section 2.1 of the SRS which follows in this module for a more detailed understanding  IEEE Software About Requirements (in Requirements Specification general)  As we’ve already discussed in Module-01, requirements are meant to tell us what the system needs to do (as opposed to how it will do it)  The what of the system tells us about the workings, functionality and behaviour of the system …  This information is communicated and grouped into 2 different styles of requirements – functional requirements and non-functional requirements  Functional Requirements  These requirements document the fundamental actions of the system. When you think about capturing the functionality and behaviour of a system – the functional requirements form the largest set requirements  These actions are often captured and described in “input-process- output” (IPO) order  Statements that indicate when an input or stimulus is given to the system [the input], the system responds by performing some task(s) or action(s) [the process] and produces an output or different system state [the output]  IEEE Software About Requirements (in Requirements Specification general)  Non-Functional Requirements  These requirements are meant to capture details about the system other than the functional behaviour / actions of the system  They capture and discuss the other facets and abilities of the system – often referred to as System Attributes  These include the maintainability, portability, securability, reliability, availability, serviceability, usability and installability of the system  They capture details about how the system will be able to recover from power failure, how it will be maintained and supported, how it will be installed, …  For more detail, please see the descriptions of Section 3.2 (functional) and Section 3.6 (non-functional) of the SRS which follows in this module Requirement s Specific Details about the IEEE SRS Specification  IEEE Software Requirements Specification IEEE Standard – Why to use  As we discussed in the previous lesson, in order to avoid  project chaos  development mayhem  customer dis-satisfaction … we need to properly, accurately and correctly document our Software Requirements !  When you need to write an SRS next semester, you’ll be using the IEEE 830-1998 Standard to guide you.  Let me take a couple of minutes to review the IEEE Specification with you …  IEEE Software Requirements Specification The Nature of the SRS  Whilewriting an SRS, the basic ideas and issues that you must address and capture are :  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, etc.?  Attributes  What are the portability, correctness, maintainability, security, etc. considerations?  Design constraints  Are there any required standards in effects, implementation language, policies for database integrity, resource limits, operating environments, etc.?  IEEE Software Requirements Specification Where the SRS is used in the overall Project  The SRS plays an important role in the life of a software project and as such, it is very important that the SRS :  Correctly define all of the software requirements so that anyone reading the document will know exactly  What the software will do  What the software won’t do  How it will operate and in what modes  What will happen as a user interacts with it  etc.  Not describe any design or implementation details  Not impose additional constraints on the software  In a software project, the SRS forms the cornerstone of understanding of the software product !!  IEEE Software Requirements Specification Characteristics of a Good SRS  In Module-01, we covered these characteristics – but here they are again:  Understandable by the End-User  Non-Prescriptive  Correct  Complete  Concise  Clear  Precise  Unambiguous  Consistent  Traceable  Modifiable  Verifiable  Usable during the Maintenance Phase of the SDLC  IEEE Software Requirements Specification If this were a Real Project … Prototyping  Inreal projects, it is quite a common technique and practice to construct (somewhat) workable prototypes of the system / program during the requirements gathering phase  This is a useful idea because:  The customer may be more likely to view the prototype and react to it than to read the SRS  It displays unanticipated aspects of the system's behaviour  An SRS based on a prototype tends to undergo less change during development  IEEE Software Requirements Specification These are Requirements … beware of Design  Ithas been said that “Every requirement limits design alternatives.”  Let’s pause to think what this might mean – because it is true  The SRS writer(s) must clearly distinguish between identifying required design constraints and projecting a specific design  You need to remember that you are documenting what to do, not how to do it !  IEEE Software Requirements Specification The Structure of an SRS*  Table of Contents  1. Introduction  1.1 Purpose  1.2 Scope  1.3 Definitions, Acronyms, and Abbreviations  1.4 References  1.5 Overview * NOTE : These are the sections that would be in your final SRS while using the IEEE Standard  IEEE Software Requirements Specification  2. Overall Description  2.1 Product Perspective  2.2 Product Functions  2.3 User Characteristics  2.4 Constraints  2.5 Assumptions and Dependencies  2.6 Apportioning of Requirements  IEEE Software Requirements Specification  3. Specific Requirements  3.1 External Interfaces  3.2 Functions  3.3 Performance Requirements  3.4 Logical Database Requirements  3.5 Design Constraints  3.6 Software System Attributes  Appendices (e.g. Appendix A, Appendix B, …)  IEEE Software Requirements Specification Section 1 - Introduction  This entire section and all of its sub-sections are about the SRS itself  The purpose of the SRS  Who should read the SRS  How to read the SRS  Research and sources used in creating the SRS  Definition of terms and acronyms used in the SRS  Asa result, Section 1 is usually the smallest section in the entire SRS  IEEE Software Requirements Specification 1.1 - Purpose  Should:  Tell the reader the purpose of the SRS  Why is this document being written ? What is the system / product that this SRS is describing?  Specify the intended audience for the SRS  Who should be reading this document ? Executives, customers, product managers, developers, etc. ?  IEEE Software Requirements Specification 1.2 - Scope  Should:  Identify the product to be produced by name  Include a brief explanation what the product will and, if necessary, will not do – a brief description of the product features  Describe the benefits of the software being specified, including its objectives, and goals  Be consistent with similar statements in higher-level specifications if they exist  NOTE The descriptions and explanations in this section should be fairly high level and not get into too many specifics. The description provided should almost be a 1 to 3 paragraph description you would find in a marketing pamphlet for the product.  IEEE Software Requirements Specification 1.3 - Definitions, etc.  Define all terms, acronyms and abbreviations found within the SRS  Not all of the document’s audience are technical people and may not know exactly what every acronym or term means  Including this section makes the document more readable by a wider audience  IEEE Software Requirements Specification 1.4 - References  Should:  Provide a complete list of all documents referenced elsewhere in the SRS  Identify each document by title, report number (if applicable), date, and publishing organization – using the APA standard  Specify the sources from which the references can be obtained  IEEE Software Requirements Specification 1.5 - Overview  Should:  Describe what the rest of the SRS contains  Explain how the SRS is organized  Tell the reader what will be found in Sections 2 and 3 of the SRS and how they are laid out – perhaps even the intended audience for each of the sections … you are trying to tell the audience what and how to read the rest of the SRS  IEEE Software Requirements Specification Section 2 – Overall Description  This section of the SRS should describe the general factors that affect the product and its requirements  This section does not state specific requirements  Instead, it provides a background for those requirements, which are defined in detail in Section 3 of the SRS, and makes them easier to understand  Thinkof Section 2 as a high-level overview when it comes to defining the functionality and purpose of the software  IEEE Software Requirements Specification 2.1 - Product Perspective  Should put the product into perspective with other related products  If the software being defined and specified is part of a larger system – then make sure to say this here. Also talk about the larger system and give references to documents about it  If the software being defined is self-contained then this should be stated here  Itcan be beneficial to include a block diagram (also known as a context diagram) of the system showing the major components, the interconnections and the external interfaces  IEEE Software Requirements Specification  Section2.1 should also describe how the software operates and interacts with the world around it by describing : 2.1.1 System Interfaces  Does the software call upon other unrelated systems to perform some function ?  Name each external system and describe how / what the software does and needs that system to do for it 2.1.2 User Interfaces  Thelogical characteristics of each UI between the software and the user  This can include descriptions of the required screen formats, page or window layouts, contents of reports and menus, use of special buttons and function keys  Often times rather than describing all of this content in words it is much more preferable (from the writer’s and the reader’s standpoint) to include UI mock-ups here A list of considerations to think about for the UI from the user’s perspective  IEEE Software Requirements Specification 2.1.3 Hardware Interfaces  Describehow the software interfaces with the hardware within the system. If the software directly manipulates (i.e. not through an API or library of calls) the hardware then it needs to be described here 2.1.4 Software Interfaces  Describehow the software product will interface with other required software products or other applications  Does the software have a need to call upon a database? directly manipulate and use the O/S? use a supporting mathematical software package? talk to the system hardware through an API?  Detailthe purpose for interfacing with this other software  Specify the name of software being interfaced to, its version, where it comes from and make reference to any documentation specifying the interface 2.1.5 Communications Interfaces  Does the software directly use any underlying communication protocol ? If so, you need to specify that protocol here.  IEEE Software Requirements Specification 2.1.6 Memory Constraints  This is where you state your considerations and expectations / limits on memory for the software ?  Is amount of memory used a concern for the software ? Is memory limited within the system – state it here. 2.1.7 Operations  Listand describe the various modes of operation of the software here  e.g. user set-up mode, administration mode, general operation mode, etc.  Can the software operate in unattended mode ?  If applicable also make note of the backup and recovery operations of the software  Note that sometimes modes of operation are also referenced in the User Interfaces subsection 2.1.8 Site Adaptation Requirements  This section describes any customization that needs to be done or considered when the software is installed at a location  Is there any setup or configuration that is necessary when installing?  IEEE Software Requirements Specification 2.2 - Product Functions  This section should provide a summary of the major functions that the software will perform  Do not go into too much detail and do not provide any specific requirements … this section really serves as a summary version of the software’s functionality  Even though this section is a summary of the functionality of the system and should not get into low-level detailed requirements – this section still needs to fully describe the system being documented and all of its features, functions, abilities, etc.  Remember the intended purpose and audience for Section 2 of the SRS  Either generally a non-technical person or the section provides an introduction to low-level details and requirements of Section 3   IEEE Software Requirements Specification 2.3 - User Characteristics  In this section you need to describe what expectations the system and software has on its users in terms of their :  Level of training and experience  Education  Technical expertise and/or background  IEEE Software Requirements Specification 2.4 - Constraints  General description of any other items that will limit the architect’s and developer's options. For example:  Regulatory policies  Hardware limitations  Interfaces to other applications  Parallel operation  Audit functions  Control functions  Higher-order language requirements  Signal handshake protocols  Reliability requirements  Criticality of the application  Safety and security considerations  In this section, you list and describe any considerations that must be taken into account when architecting and designing the software  IEEE Software 2.5 - Assumptions and Requirements Specification Dependencies  In this section, you list and describe any factors that may affect requirements stated in the SRS  For example, if an assumption that a specific Operating System will be available on the hardware and it ends up not to be the case, then this would affect the contents of the SRS  Basicallywhat you are trying to capture in this section are any known external considerations that are being assumed in the writing of the requirements for the software  And if these assumptions end up changing – then the software’s requirements may need to change as well  In essence, this section is used to list and  IEEE Software Requirements Specification A Note about TBD’s  What’s a TBD ?  Strictly speaking according to the IEEE Specification, in order to be a complete SRS – there must not be any TBD’s in the document.  But as we know, stuff happens and as a result, the software that we are trying to describe may (at the time of writing the SRS) have unknowns or assumptions that need to be made …  In this case we need to document the TBD fully (more on this in the supplementary Creating an SRS Module)  IEEE Software 2.6 - Apportioning of Requirements Specification Requirements  What does Apportioning mean ?!?  Apportioning means the “putting off of”  So in terms of the SRS – this means that you need to identify requirements that may be delayed until future versions of the system  If there is a known requirement that has been mentioned and at the time of writing the SRS, you know that it will be put off until a future release, then document it here  When a requirement is apportioned – this is the only place in the SRS where that requirement is mentioned – no where else! Section 3 - Specific IEEE Software Requirements Specification Requirements  This section contains all of the requirements to a level of detail  This is where the meat and potatoes of the SRS is found. sufficient to enable: a) Designers to design a system to satisfy those requirements b) Testers to test that the system satisfies those requirements  Also remember to follow these principles  All requirements should be uniquely identifiable (and traceable) Yum!!!  Attention should be paid to organizing the requirements for maximum readability and comprehension  Other things to consider in documenting your requirements … they:  Should describe each input (stimulus) to the system.  Should describe all functions performed by the system in response to an input or in support of an output.  Should describe each output (response) from the system.  This is known as IPO Order (Input / Process / Output)  IEEE Software Requirements Specification Types of Specific Requirements  3.1 External Interfaces  3.2 Functions  3.3 Performance Requirements  3.4 Logical Database Requirements  3.5 Design Constraints  3.6 Software System Attributes NOTE: There are many different ways of laying out Section 3 – but in all of the different organizations, these subsections need to be present  IEEE Software Requirements Specification 3.1 - External Interfaces  This section should contain a detailed description of all inputs into and outputs from the software.  It should complement the interface descriptions from Section 2 (in Section 2.1) and be broken out into the same sub-sections (i.e. 3.1.1 through 3.1.5)  Generally we describe the low-level requirements of the various interfaces as inputs and outputs … remember that these interfaces describe how the system you are capturing the requirements for talks to / depends on / interacts with other systems, underlying hardware, underlying software, communication schemes, etc.  It is best to think and describe the interface interactions as a set of inputs and outputs  For each input or output specified you should specify  The input / output name  You will refer to this input / output by name in Section 3.2  Description of purpose  Source of input or destination of output  Where does it come from or where is it going to ?  Relationships to other inputs / outputs  The format of the input / output  Whether that be screen format, window format, data format or command format  IEEE Software Requirements Specification 3.2 - Functions  Thisis the section of the SRS where a major portion of the software’s requirements are specified !  This section contains the software’s functional requirements  This section describes the fundamental actions that must take place in the software in processing the inputs and generating outputs  Requirements are specified as the shall statements (“The system shall …”)  In specifying the requirements remember to include  validity checks on the inputs  exact sequence of operations  responses to abnormal situations  effect of parameters  relationships of outputs to inputs  It may be appropriate to break the functional requirements into sub-functions (or sub-processes)  Based on logical subsystems of the software, or modes of operation of the software, etc.  IEEE Software Requirements Specification 3.3 - Performance Requirements  This sections lists the static and dynamic numerical requirements placed on the software or on the human interaction with the software  Examples of static:  number of users  amount of information  Examples of dynamic:  numbers of transactions to be processed within certain time periods for normal and peak workload conditions  If known, then all requirements given in this section should be stated in measurable terms. For example:  95% of the transactions shall be processed in less than 1 second.  I’m going to ask you to see if you remember … where do you get these Performance Requirements?  From the CUSTOMER … the person describing the system and telling you about the system’s behaviour … Never ever never MAKE UP REQUIREMENTS!!  IEEE Software Requirements Specification 3.4 - Logical Database Requirements  The requirements for any information that is to be placed in a database should be specified here  Remember that a database is really any collection or organization of data  Practically every system has data that is used and manipulated and needs to be retained (e.g. clock alarms, radio presets, …)  The requirements for the database need to include:  The data entities used in the software (use the same name that you referred to the data as in Section 3.2 and elsewhere)  Any relationship that the data entities have to one another  The frequency of use of the data  What subsystems or mode of operation will be accessing and manipulating the data ?  The data retention requirements  IEEE Software Requirements Specification Database Example  Let’s say I am writing the requirements for a piece of software tracking a patient during a hospital stay. And specifically I am looking at tracking the patient’s location and any medications that they need to be given and take …  According to the requirements that I have gathered, I need to track the patient’s name, date of birth (DOB), health card number (HCN), the room and bed that the patient is presently in and list of medications (up to 20) that the patient takes  For each medication, I need to track the drug identification number (DIN), the frequency that the patient takes the medication, the amount that is taken at each interval, the date that the user started taking the medication as well as the date that the user can stop taking the medication  So think about the information in the last 2 bullet points … that is A LOT of detail – a lot of pieces of data! In our SRS for this Patient Care System, we need to capture all of the detail of this data and organize it in some fashion so that we can understand:  What pieces of data the system is capturing / holding / manipulating  Any attributes/members and relationships that may exit between the various pieces of data  How long we expect that the system needs to “remember” this data  IEEE Software Requirements Specification Database Example (cont’d) Data Attributes / Used in Retention Entity Relationship(s) System? PatientID Patient Name, Used anytime patient The PatientID and it attributes are Date of Birth (DOB), information is retained for the entire duration of Health Card Number (HCN) accessed within the hospital stay system - This entity uniquely identifies a patient in the hospital PatientLocation Room, Used in FindPatient Will only ever be 1 room/bed combo Bed requirements (see – but will/can change multiple times Section 3.2.2). during stay MedicationList Medication Used throughout Each patient will always have a entire system – when MedicationList (even if it is empty). - Contains up to 20 Medication gathering medication It will stay with the patient during entities list, when looking up their entire hospital stay. The individual medications in the list may medication list, when change – but the list will always be adjusting medication present list (see Sections 3.2.3, 3.2.4, 3.2.5, 3.2.6) Medication DIN, Used through entire Given that a medication has a start Frequency of Taking, system just as the and stop date, it is important for the Quantity, MedicationList is system to track the system’s current Start Date, date. Stop Date When the current date > medication start date – the system automatically adds this medication to the list being dispensed to the patient (see Section 3.2.5)  IEEE Software Requirements Specification 3.5 - Design Constraints  Specify design constraints that can be imposed by standards compliance, hardware limitations, etc.  For example  If your software must be written in C# you would state it here  If you had to follow Six Sigma Quality Management in your organization, you would state it here  If your system only had 1 GByte of RAM, you would state it here  This section should contain the same basic information that was given in Section 2.4 … but in more specific detail. And also perhaps some reasoning / justification why the constraints exist.  IEEE Software Requirements Specification 3.6: Software System Attributes  There are a number of attributes of a software product (system) that serve as requirements  These are often referred to as the non-functional requirements  It is important to include these attributes so that their achievement can be objectively verified  These attributes can include :  According to the IEEE Specification : Reliability, Availability, Security, Maintainability, Portability  Another common breakdown of these attributes are : Reliability, Availability, Serviceability, Usability and Installability  IEEE Software Requirements Specification Organizing the Specific Requirements  Okay, so now you know what (in terms of details) needs to go into Section 3 of the SRS … but how should you organize that section ?  There are many different ways of organizing Section 3 – depending on the software system, some methods are better than others  Different organizational models include:  System Mode  When there are different modes of operation within the software  User class  When the software behaves differently depending on the type of user  Objects  If your software interacts with different objects (eg. Patient Monitoring System interacts with objects : patient, sensors, nurses, room …)  Features  If the system has a number of externally desired services  IEEE Software Requirements Specification Organizing the Specific Requirements  Other organizational models include:  Stimulus  Some systems are best organized by describing the requirements on a per stimulus (input) basis  Response  Same idea as stimulus, but on a per output (response) basis  Functional hierarchy  if all else fails, organize in this way – according to the functional areas of the software  There are templates that are made available for each one of these organizational models of the Specific Requirements  They are found in Annex (Appendix) A of the IEEE Standard