| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-BdYFG4-dbPBGFzF9z6KGPA" |
| name="supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q" guid="-BdYFG4-dbPBGFzF9z6KGPA" |
| changeDate="2006-12-21T09:43:46.709-0800" version="1.0.0"> |
| <mainDescription><p>
 |
| There is a finite set of requirements to consider when it comes to gathering system-wide requirements, qualities, or
 |
| constraints. Many of them are unfamiliar to stakeholders; therefore, they may find it difficult to answer questions
 |
| related to topics such as availability, performance, scalability, or localization. You can use this guideline and the
 |
| associated checklist <a class="elementLinkWithType" href="./../../../openup/guidances/checklists/supporting_requirements_3158BF2F.html" guid="_Vael8CGMEdu3VKXZx45D3A">Checklist: Supporting Requirements</a>&nbsp;when speaking to stakeholders to ensure that
 |
| all topics are discussed. Make sure that stakeholders understand the costs of their selections and do not end up
 |
| wanting everything that is on the list.
 |
| </p>
 |
| <h3>
 |
| Functional
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Auditing:</strong> Is there a need to track who used the system and when they used it? State
 |
| requirements for providing audit trails when running the system.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Authentication:</strong> Will access to the system be controlled? State requirements for
 |
| authentication.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Licensing:</strong> Will the system or parts of the system be licensed? If open-source software has
 |
| been used in the system, have all open-source agreements been respected? State requirements for acquiring,
 |
| installing, tracking, and monitoring licenses.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Printing:</strong> Will printing capability be required? State requirements for printing.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Reporting:</strong> Is reporting capability required? State requirements for reporting.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Scheduling:</strong> Will certain system actions need to be scheduled? State requirements for
 |
| scheduling capability.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Security:</strong> Will elements of the system or system data need to be secure? State requirements to
 |
| protect access to certain resources or information.
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Usability
 |
| </h3>
 |
| <p>
 |
| Usability requirements are critical to the success of any system. Unfortunately, usability requirements are often the
 |
| most poorly specified requirements. Consider this common requirement: The system shall be easy to use. This doesn't
 |
| help much, because it cannot be verified.
 |
| </p>
 |
| <p>
 |
| While capturing usability requirements, it is a good idea to identify issues and concerns first, and then refine these
 |
| into verifiable requirements later (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/writing_good_requirements_48248536.html" guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a>). According to a traditional definition,
 |
| usability consists of five factors:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Ease of learning:</strong> A user with a specified level of experience must be able to learn how to use
 |
| the system in a specified amount of time.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Task efficiency:</strong> A user should be able to complete a specified task in a specified time (or
 |
| number of mouse clicks).
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Ease of remembering:</strong> A user should be able to remember how to accomplish specified tasks after
 |
| not using the system for a specified period of time.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Understandability:</strong> A user must be able to understand system prompts and messages and what the
 |
| system does.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Subjective satisfaction:</strong> A specified percentage of the user community must express
 |
| satisfaction with using the system.
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| You may want to use the following method to identify and specify usability requirements:
 |
| </p>
 |
| <div style="MARGIN-LEFT: 2em">
 |
| <ol>
 |
| <li>
 |
| Identify the key usability issues by looking at critical tasks, user profiles, system goals, and previous
 |
| usability problems.
 |
| </li>
 |
| <li>
 |
| Choose the appropriate style to express the requirements: 
 |
| <ul>
 |
| <li>
 |
| <strong>Performance style:</strong> Specify how fast users can learn various tasks and how fast they
 |
| can perform the tasks after training.
 |
| </li>
 |
| <li>
 |
| <strong>Defect style:</strong> Rather than measuring task times, identify usability defects and
 |
| specifies how frequently they may occur.
 |
| </li>
 |
| <li>
 |
| <strong>Guideline style:</strong> Specify the general appearance and response time of the user
 |
| interface by reference to an accepted and well-defined standard
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| Write the actual requirements, including performance criteria (see <a class="elementLinkWithType" href="./../../../openup/guidances/guidelines/writing_good_requirements_48248536.html" guid="_6jXzYNcKEdqz_d2XWoVt6Q">Guideline: Writing Good Requirements</a>&nbsp;for more information).
 |
| </li>
 |
| </ol>
 |
| </div>
 |
| <h3>
 |
| Reliability
 |
| </h3>
 |
| <p>
 |
| Reliability includes the system's ability to continue running under stress and adverse conditions. In the case of an
 |
| application, reliability relates to the amount of time that the software is available and running as opposed to time
 |
| unavailable. Specify reliability acceptance levels, as well as how they will be measured and evaluated. Describe
 |
| reliability criteria in measurable terms. This is usually expressed as the allowable time between failures or the total
 |
| allowable failure rate. Other important reliability considerations include:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Accuracy:</strong> Specify requirements for the precision (resolution) and the accuracy (by some known
 |
| standard) that is required in any calculation performed or in system output.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Availability:</strong> Specify requirements for the percentage of time the system is available for use,
 |
| hours of use, maintenance access, and degraded-mode operations. Availability is typically specified in terms of
 |
| the Mean Time Between Failures (MTBF).
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Recoverability:</strong> Specify requirements for recovery from failure. This is typically specified in
 |
| terms of the Mean Time to Repair (MTTR).
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Frequency and severity of failures:</strong> Specify the maximum defect rate (typically expressed as
 |
| defects/KSLOC or defects/function-point) and severity of failures. Severity&nbsp;may be categorized in terms of
 |
| <strong>minor</strong>, <strong>significant</strong>, and <strong>critical</strong> defects. The requirements
 |
| must define each of these terms unambiguously. For example, a <strong>critical</strong> defect could be defined
 |
| as one that results in loss of data or complete inability to use certain functionality of the system.
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Performance
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Response times:</strong> Specify the amount of time available for the system to complete specified
 |
| tasks and transactions (average, maximum). Use units of measurement. <em>Examples:</em>
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Any interface between a user and the system shall have a maximum response time of 2 seconds.
 |
| </li>
 |
| <li>
 |
| The product shall download the new status parameters within 5 minutes of a change.<br />
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| <strong>Throughput:</strong> Specify the capacity of the system to support a given flow of information (for
 |
| example, transactions per second).<br />
 |
| </li>
 |
| <li>
 |
| <strong>Capacity:</strong> Specify on the volumes that the product must be able to deal with and the numbers of
 |
| data stored by the product. Make sure that the requirement description is quantified, and thus can be tested. Use
 |
| unit of measurement such as: the number of customers or transactions the system can accommodate, resource usage
 |
| (memory, disk, . . . ) or degradation modes (what is the acceptable mode of operation when the system has been
 |
| degraded in some manner) <em>Examples:</em> 
 |
| <ul>
 |
| <li>
 |
| The product shall cater for 300 simultaneous users within the period from 9:00 AM to 11 AM.
 |
| </li>
 |
| <li>
 |
| Maximum loading at other periods will be 150.<br />
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| <strong>Start-up:</strong> The time for the system to start up.<br />
 |
| </li>
 |
| <li>
 |
| <strong>Shut-down:</strong> The time for the system to shut down.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Supportability
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Adaptability:</strong> Are there any special requirements regarding adaptation of the software
 |
| (including upgrading)? List requirements for the ease with which the system is adapted to new environments.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Compatibility:</strong> Are there any requirements regarding this system and its compatibility with
 |
| previous versions of this system or legacy systems that provide the same capability?
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Configurability:</strong> Will the product be configured after it has been deployed? In what way will
 |
| the system be configured?
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Installation:</strong> State any special requirements regarding system installation
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <strong>Level of Support:</strong> What is the level of support that the product requires? This is often done using
 |
| a Help desk. If there are to be people who provide support for the product, is that support considered part of what
 |
| you are providing to the customer? Are there any requirements for that support? You might also build support into
 |
| the product itself, in which case this is the place to write those requirements. Consider the level of support that
 |
| you anticipate providing and what forms it might take.<br />
 |
| </li>
 |
| <li>
 |
| <strong>Maintainability:</strong> Are there any special requirements regarding system maintenance? What are the
 |
| requirements for the intended release cycle for the product and the form that the release will take? Quantify the
 |
| time necessary to make specified changes to the product. There may also be special requirements for
 |
| maintainability, such as&nbsp;a requirement that&nbsp;the product must be able to be maintained by its end-users or
 |
| developers who are not your development team. This has an effect on the way that the product is developed, and
 |
| there may be additional requirements for documentation or training. Describe the type of maintenance and the amount
 |
| of effort required. <em>Examples:</em><br />
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| <ul>
 |
| <li>
 |
| A new weather station must be able to be added to the system overnight.
 |
| </li>
 |
| <li>
 |
| The maintenance releases will be offered to end-users once a year.<br />
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| <strong>Scalability:</strong> What volumes of users and data will the system support? This specifies the expected
 |
| increases in size that the product must be able to handle As businesses grow (or are expected to grow), the
 |
| software products must increase their capacities to cope with the new volumes. This may be expressed as a profile
 |
| over time.<br />
 |
| </li>
 |
| <li>
 |
| <strong>Testability:</strong> Are there any special requirements regarding the testability of the system?
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Constraints (+)
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Design constraints:</strong> Are there any design decisions that have been mandated that the product
 |
| must adhered to?
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Third-party components:</strong> Specify any mandated legacy, COTS, or open-source components to be
 |
| used with the system.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Implementation languages:</strong> Specify requirements on the implementation languages to be used
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Platform support:</strong> Specify requirements on the platforms that the system will support
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Resource limits:</strong> Specify requirements on the use of system resources, such as memory and hard
 |
| disk space
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Physical Constraints:</strong> Specify requirements on the shape, size, and weight of the resulting
 |
| hardware to house the system
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Interface Requirements (+)
 |
| </h3>
 |
| <p>
 |
| Describe both the user interface and interfaces with external systems.
 |
| </p>
 |
| <h4>
 |
| User interface
 |
| </h4>
 |
| <p>
 |
| Describe requirements related to user interfaces that are to be implemented by the software. The intention of this
 |
| section is to state the requirements, but not to describe the user interface itself, because interface design may
 |
| overlap the requirements-gathering process. This is particularly true if you are using prototyping as part of your
 |
| requirements gathering process. As you develop prototypes, it is important to capture the requirements that relate to
 |
| the look and feel of the user interface. In other words, be sure that you understand your client’s intentions for the
 |
| product’s look and feel. Record these as requirements, rather than merely using a prototype for approval.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Look and feel:</strong> A description of the aesthetic appearance and layout of the interface. Your
 |
| client may have given you particular demands, such as style, colors, degree of interaction, and so on. This
 |
| section captures the requirements for the interface, rather than the design for the interface. The motivation
 |
| is to capture the expectations, the constraints, and the client’s demands for the interface before designing
 |
| it. <em>Examples:</em>
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The product shall have the same layout as the district maps from the engineering department.
 |
| </li>
 |
| <li>
 |
| The product shall use the company color.<br />
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| <strong>Layout and navigation requirements:</strong> Specify requirements on major screen areas and how they should
 |
| be grouped together.<br />
 |
| </li>
 |
| <li>
 |
| <strong>Consistency:</strong> Consistency in the user interface enables users to predict what will happen. This
 |
| section states requirements on the use of mechanisms to be employed in the user interface. This applies both within
 |
| the system, and with other systems and can be applied at different levels: navigation controls, screen areas sizes
 |
| and shapes, placements for entering / presenting data, terminology<br />
 |
| </li>
 |
| <li>
 |
| <strong>User personalization and customization requirements:</strong> Requirements on content that should
 |
| automatically displayed to users or available based on user attributes. Sometimes users allowed to customize the
 |
| content displayed or to personalize displayed content.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Interfaces to external systems or devices
 |
| </h4>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Software interfaces:</strong> Are there any external systems with which this system must interface? Are
 |
| there any constraints on the nature of the interface between this system and any external system, such as the
 |
| format of data passed between these systems? Do they use any particular protocol? Describe software interfaces
 |
| with other components. These may be purchased components, components reused from another application, or
 |
| components being developed for subsystems outside of the scope of the system under consideration, but with
 |
| which this it must interact. For each system, consider both provided and required interfaces.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Hardware interfaces:</strong> Define any hardware interfaces that are to be supported by the software,
 |
| including logical structure, physical addresses, expected behavior, and so on.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Communications interfaces:</strong> Describe any communications interfaces to other systems or devices,
 |
| such as local area networks (LANs), remote serial devices, and so on.
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Business Rules (+)
 |
| </h3>
 |
| <p>
 |
| Besides technical requirements, also consider the particular business domain in which the system needs to fit.
 |
| </p>
 |
| <p>
 |
| Business rules or policies that the system must conform to may constrain system functionality. Business rules are
 |
| referred to by system use cases and can be in the form of decision tables, computation rules, decision trees,
 |
| algorithms, and so forth. Describing the rules in the flows of the use cases usually clutters the use-case
 |
| specifications. Therefore, they are normally captured in separate artifacts or as annexes related to the use-case
 |
| specifications. In many cases, a business rule applies to more then one use case. Shared business rules should be
 |
| stored in a single repository, such as a supporting requirements document.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
