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