Task: Develop Supplementary Specifications









var defaultQueryStr = '?proc={38A9C609-9A59-4D03-B835-AA84A716E626}&path={38A9C609-9A59-4D03-B835-AA84A716E626},{20E30ECF-7359-45EC-AA5F-8A7BFA21C472},__YvW7EogEdqrjq4i3fchvA';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=[{view: "view:_e_O28N7KEdm8G6yT7-Wdqw", path: ["_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vChNR0JHEdq4z9xc-r201w", "_vCtaiEJHEdq4z9xc-r201w", "_rnmKIJ4_Edq7s5zuJVEAAw", "__YvW7EogEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_PEpmMCVuEdqSZ9OimJ-AzA", "_vyZOwCVuEdqSZ9OimJ-AzA", "_o3nZoSFrEdqrX8YVzvtlIg", "_2qqegCGGEdqMcovRzkCQow", "__YvW7EogEdqrjq4i3fchvA"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_e_O28N7KEdm8G6yT7-Wdqw", "_vCtak0JHEdq4z9xc-r201w", "_vChNR0JHEdq4z9xc-r201w", "_vCtaiEJHEdq4z9xc-r201w", "_rnmKIJ4_Edq7s5zuJVEAAw", "__YvW7EogEdqrjq4i3fchvA"]}];
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, true, true, false);










Task: Develop Supplementary Specifications















This task captures the requirements that do not apply to specific use cases.






Purpose



To capture requirements that are not readily captured in Use Cases.



Relationships



RolesMain:



System Analyst


Additional:



Requirements Specifier


Assisting:



InputsMandatory:



Iteration Plan


Stakeholder Requests


Optional:



Business Case


Glossary


Vision


External:


None




Outputs


Supplementary Specifications






Main Description



Throughout the requirements activities, based upon the stakeholder requests that have been gathered, requirements that are not applicable to specific Use Cases are captured in the Supplementary Specification. Both functional and non-functional requirements may be captured in the Supplementary Specification.  For more information in categorizing and capturing requirements, see Concept: Requirements. While performing this task it is important to make sure that all requirements are specified to the level of detail needed to hand off to designers, testers and documentation writers. If requirements are traced or otherwise formally managed, make sure that each requirement is clearly identified and labeled.



Steps




Capture Non-Use-Case-Specific Functional Requirements



Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities [MAL2001]. While many of the functional requirements will be documented in Use Cases, there are some functional requirements that cannot be applied to specific use cases.  For example, reporting, auditing, printing, security, licensing support/enforcement, authentication requirements, etc.  Such functional requirements should be documented in the Supplementary Specification.   If there are a significant number of system-wide functional requirements, it is important to give some thought into the organization of this section.  A typical organization is by feature/feature set, but alternative organization methods are also possible.  For example, organization by user or organization by subsystem, may also be appropriate. Functional requirements represent the 'F' in "FURPS+.  For more information on "FURPS+", see Concept: Requirements.



Capture System Qualities



Non-functional requirements include both qualities and constraints [MAL2001].  In this step we discuss qualities.  Constraints are addressed in a separate step. [System] qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. [MAL2001] Qualities represent the "URPS" in "FURPS+".  The concerns of each of these categories of requirements is as follows: Usability:  Aesthetics and consistency in the user interface. Reliability:  Availability (the amount of system "up time"), accuracy of system calculations, and the system's ability to recover from failure. Performance: Throughput, response time, recovery time, start-up time, and shutdown time. Supportability: Testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability. For more information on "FURPS+", as well as capturing non-functional requirements, see Concept: Requirements. Depending on the number of qualities to be documented for the system, you may want to provide sub-sections for each of these quality types. The following sections provide some examples of the kids of information you might want to capture for each of these qualities: Usability When describing usability requirements, you may want to specify: Required training time for a normal users and power users to become productive at particular operations Measurable task times for typical tasks Requirements to conform to common usability standards, for example, IBM's CUA standards or Microsoft's GUI standards Reliability When describing reliability requirements, you may want to specify: Availability – specify percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, and the like. Mean Time Between Failures (MTBF) – this is usually specified in hours but it could also be specified in terms of days, months or years. Mean Time To Repair (MTTR) – how long is the system allowed to be out of operation after it has failed? Accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the systems output. Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs/function-point. Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a "critical" bug; for example, complete loss of data or complete inability to use certain parts of the functionality of the system. Performance When describing performance requirements, you may want to specify: Response time for a transaction(average, maximum) Throughput (for example, transactions per second) Capacity (for example, the number of customers or transactions the system can accommodate) Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner) Resource use: memory, disk, communications, and so forth When documenting performance requirements, be sure to include specific response times. Where applicable, reference related Use Cases by name. Supportability When describing supportability requirements, you may want to specify: Coding standards Naming conventions Class libraries Maintenance access Maintenance utilities



Capture Constraints



In this step you document any design constraints on the system being built. In general terms, a constraint is a restriction on the degree of freedom we have in providing a solution [LEF2000].  Design constraints represent design decisions that have been mandated and must be adhered to.  A Constraints represent the '+' in "FURPS+" and can be further categorized, as follows: Design constraint: Specifies or constrains the options for architecting and/or designing a system. For example, requiring that a relational database be used for persistence. Implementation constraint: Specifies or constrains the coding or construction of a system. For example, required standards, processes, tools, implementation languages, hardware platforms, operating systems, third-party components, class libraries, and resource limits (use of memory or disk space). Interface constraint: Specifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction.  For example, interfacing with an external system via message queues. Physical constraint: Specifies a physical constraint imposed on the hardware used to house the system â€" shape, size, or weight, for example. Depending on the number of constraints to be documented for the system, you may want to provide sub-sections for each of the constraint types. Additionally: If the requirements include the purchase of third-party components, be sure to document any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards. A separate section per purchased component is recommended. If the requirements include specific interface requirements, it is recommended that you provide separate sections for the different types of interfaces (e.g., user, hardware, software). For each interface, be sure to include adequate specificity, protocols, ports and logical addresses, and so forth, so that the software can be developed and verified against the interface requirements. Specifically: For user interfaces, describe the user interfaces that are to be implemented by the software. For hardware interfaces, include logical structure, physical addresses, expected behavior, and so on. For software interfaces include a description of the interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for subsystems outside of the scope of this system, but with which this software application must interact. For more information on "FURPS+", as well as capturing constraints, see Concept: Requirements.



Capture Compliance Requirements



By compliance, we include standards compliance (including regulatory standards, coding standards or user interface style guides), as well as legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, and/or logo compliance. Compliance requirements may be realized in terms of other requirements (functional, non-functional, and constraints).  In such cases, the details of those requirements should be documented in the applicable sections of the Supplementary Specification as described in the earlier steps.  However, it is important to summarize the standards and policies that a system must comply with.  The resulting compliance requirements may refer to the applicable detailed requirements, as necessary. Depending on the number of compliance requirements to be documented for the system, you may want to provide sub-sections for the different kinds of compliance affecting the system. The following sections provide some examples of the kids of information you might want to capture for different kinds of compliance: Licensing Requirements Define any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software. Legal, Copyright, and Other Notices Describe any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, or logo compliance issues for the software. Applicable Standards Describe (by reference) any applicable standards and the specific sections of any such standards that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth.



Capture Documentation Requirements



In this step, you describe the requirements, if any, for documentation. Documentation requirements may include requirements for online help, as well as and end-user documentation (e.g., installation guides, user's guides, training material, etc.).   Like compliance requirements, documentation requirements drive other types of requirements.  Specifically functional requirements (the system must provide support functional access to the online help), as well as usability requirements (on demand access to system usage information supports the overall usability of the system).  Thus, like compliance requirements, detailed requirements supporting documentation requirements should be documented in the applicable sections of the Supplementary Specification as described in the earlier steps, but it is also important to document and summarize the overall documentation requirements for the system. The resulting requirements may refer to the applicable detailed requirements. Depending on the number of documentation requirements to be documented for the system, you may want to provide sub-sections for the different kinds of documentation to be provided for the system.







Properties



Multiple Occurrences


Event Driven


Ongoing


Optional


Planned


Repeatable



Key Considerations



The requirements that span use cases (possibly system-wide requirements) tend to drive the development of the architecture of the system. In fact, on some projects, such requirements can be significantly more important than their more domain-specific (or use-case-specific) counterparts. For example, if you were developing medical life support systems, then reliability requirements would be critical. Unfortunately, such requirements are often difficult to gather and thus are often overlooked. This task describes the overall approach for gathering these requirements.  For more information on a "systematic" approach to gathering these requirements using specific questionnaires, see [EEL2004].



More Information



Tool Mentors


Managing Stakeholder Requests Using Rational ClearQuest and Rational RequisitePro








©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();
contentPage.processPage.fixDescriptorLinks();