menu

    Requirement Is An Atomic Unit Of Product Scope

    A Requirement is a type of contractual clause between the user and their system. A Requirement states exactly what each user can do with the system. It is important to note that a system will not perform any functions outside of those stated in the Requirements.

    There are Functional and Non-functional Requirements. A Functional Requirement answers the question "what should the system do", and a Non-functional Requirement provides an answer to "how will the system do this"?

    Functional Requirements respond when the user makes a 'Request', causing the system to create a 'Reply'. A 'Request' is a formal interaction between the user and system through one of its external interfaces. A 'Reply' is the term for how the system reacts after receiving a Request from the user. Functional Requirements are supported with Non-functional Requirements, which are supplementary specifications in a SRS.

    Examples of Functional Requirements and their supplementary specifications include the following:

    # Requirement Supplementary
    R1User can submit a Request to change the password associated with their account, the system shall generate a Reply by changing the database records for the user. Web user interface layout, Errors list
    R2Affiliate can submit a Request for an updated report, the system shall generate a Reply with a sorted snapshot of all data for the last week. XML API Description, Errors list
    R3Administrator can submit a Request for a list of accounts sorted by the date of most recent login, the system shall generate a Reply and sorts the list accordingly. Web interface layout

    Non-functional requirements can define the following quality characteristics of the system:

    • External Interfaces and Error Codes
    • Interface Mock-ups and Graphics
    • Availability, Reliability, Performance, etc.

    Examples of Non-functional Requirements (for the classifications above) include the following:

    # Definition Class
    IF1System provides XML-based API as defined in the Protocol Description (Protocol-v1.5.pdf) via HTTPS socket.External Interface
    SS1System works without crashing during 100 hours in 5 consecutive tests with an average load of 1000 concurrent users.Reliability
    SS2System responds to any type of report request within a 500ms timeframe on the server equipment defined in SRS, and with up to 500 concurrent users, over the course of 100 minutes.Performance

    Requirements are listed in the SRS, which also includes the Glossary, Use Cases, Functional Requirements, and Non-Functional Requirements.

    Last update on
    © TechnoPark Corp., 2000-2015 ISO logo