it:ad:requirements:howto:classify_requirements

IT:AD:Requirements:HowTo:Classify Requirements

Summary

At a top level, Requirements can be classified as Business, User, and System Requirements:

The above can be categorised further as follows:

Business RequirementsUser RequirementsSystem RequirementsSupplemental RequirementsFunctional ReqsDomain Functional ReqsSystem Wide Functional ReqsConstraintsNon-Functional ReqsSystem ReqsOperational ReqsUsabilityReliabilityPerformanceSupportabilityuntestable reqs in the vocab of the sponsoruntestable reqs in the vocab of the userTestable Systemequivalents ofUser Requirements,without specifyingimplementation/howAlso referred to asQuality RequirementsConstraints definethe boundaries withinwhich System Reqscan be developed.Obligations ofthe systemused to implementuser requirementswithin Constraints

Business requirements describe the Why the money should be spent.

  • Business Requirements are collected together as the BRD.
  • The Business Requirements encompass the requirements expressed within the following:
    • Problem Statement
    • Project Vision
    • Project Constraints (Budget, Schedule, and Resources)
    • Project Objectives
    • Project Scope Statements
    • Business Process Analysis: (analyse the business process before trying to automate it)
    • Stakeholder Analysis: (who will be impacted)
  • User Requirements are a wish list of functionality desired desired by the Users.
  • User Requirements are gross requirements, that do not specify how the functionality will be delivered.
  • User Requirements are generally un-testable.
  • User Requirements are collected together in the User Requirements Document (URD).
    • The URD is signed off by the User
  • User (functional) Requirements are the basis of System Functional Requirements (see below).

Example:
1. The MHC-PMS shall generate monthly management reports showing
   the cost of drugs prescribed by each clinic during that month.

  • System Requirements are comprised of two sub sections, Functional Requirements and Supplemental/Non-Functional Requirements
  • System Functional Requirements are the conversion of non-testable User Requirements into gross, testable requirements.
  • System Functional Requirements are 'gross' testable requirements. They do not specify Design implementation detail.
  • System Functional Requirements are the basis of System (Functional) Design Requirements, which are detailed, testable, functional requirements.
  • System Supplemental Requirements are the testable requirements defining the quality to which the System is to adhere.
  • System Supplemental Requirements are the basis of System (Non-Functional) Design Requirements, which are detailed, testable, non-functional requirements.
  • Are collected together into System Requirement Documents (SRDs).

An example of a System Functional Requirement would be:

1.1. On the last working day of each month, a summary of the drugs
     prescribed, their cost, and the prescribing clinics shall be generated.
1.2. The system shall automatically generate the report for printing after
     17.30 on the last working day of the month.

  • System Design Specifications are the conversion of testable, System Requirements (both Functional and Supplemental) into fine-grain System Design Requirements.
    • They specify design and implementation details.
    • A System Design Requirement is not distinguished as a Functional/Non-Functional Requirement as it is usually considering both in order to achieve a set of individual implementation tasks.
    • It's good practice to record traceability from the SDR back to the SFR/SNFR.
    • The reality is that beyond the largest of projects, System Design Requirements are not produced. This is especially true in Agile run projects.

An example of some System Design Requirement would be:

1.1. A SummaryReportWorkflow will be developed to meet SFR-1.1
1.1.1 The SummaryReportWorkflow will include a summary of the tblDrugs records with xyz column containing a date later than foobar. 
etc.

The Use Cases are defined from the System Functional Requirements, and do not include the kind of detail that would be in System Design Requirements (and note that Use Cases are generally defined for a SAD (far earlier than Solution Design Requirements are required).

In Agile development, User Stories are written in the language of Business Users (““As a <role>, I want <goal/desire> so that <benefit>”“). In other words, they are more or less User Requirements, that do not specify the details one would expect within a System Functional Requirements or System Design Requirements.

  • IT:AD:User Storys: written in the User language, more or less equivalent to the User Requirements, lacking the testability of a System Functional Requirement, and implementation detail of a System Design Requirement.
The weakness of User Stories is in the lack of details, and acceptance criteria that are focused on meeting User Requirements and not necessarily focused on meeting System Supplemental/Non-Functional Requirements.

The Acceptance Testing of the User Story should ensure the User Requirement is met, along with meeting: * the System Functional Requirements * the System Non-Functional Requirements * the Design Functional Requirements * the Design Non-Functional Requirements

A Risk is that keeping both User Stories and NFRs in sight for each test is not easy to coordinate.

  • /home/skysigal/public_html/data/pages/it/ad/requirements/howto/classify_requirements.txt
  • Last modified: 2023/11/04 01:55
  • by 127.0.0.1