| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-BdYFG4-dbPBGFzF9z6KGPA" name="supporting_requirements,_wr24gNcGEdqz_d2XWoVt6Q" guid="-BdYFG4-dbPBGFzF9z6KGPA" changeDate="2006-12-21T12:43:46.709-0500" 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_basic/guidances/checklists/supporting_requirements,_Vael8CGMEdu3VKXZx45D3A.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_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.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_basic/guidances/guidelines/writing_good_requirements,_6jXzYNcKEdqz_d2XWoVt6Q.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> |
