UC1::Add Requirement
Overview
odlingsmee;; 2006-01-21
This use-case describes the sequence of events that allows the actor to add a new requirement in the Xuse requirements repository
Document History
  1. Current Version1.7
  2. 1.1odlingsmee; 01 Jan 2006 ; Initial Revision
  3. 1.2odlingsmee; 21 Jan 2006 ; Completed main flow of events and exception flows and alternate flows
Properties
  • TriggerA new requirement is discovered or thought of
  • GoalTo record the details of a new requirement
  • Primary ActorBusiness Analyst
  • Pre-RequisitesNone
  • Success OutcomeA new requirement will have been documented
  • Failure OutcomeThe reason for the failure to add the requirement will have been provided to the actor
  • Priority1
  • Complexity1
  • Trace to[UC2] Build HTML Site
  • Packagedataentry
Basic Flow
  1. The business-analyst opens the the [RQ1] requirements repository.
  2. The business analyst adds a new requirement to the repository giving it a [RQ4] unique id.
  3. The business-analyst [RQ43] categorises the requirement with information such as [RQ44] type; [RQ45] package; [RQ46] status and any other [RQ47] arbitrary classification as required.
  4. The business-analyst adds relationships to the requirement: these may include [RQ5] parent (trace-from) relationships as well as some relationships to show similar but not directly related requirements.
  5. The business-analyst [UC2] publishes the new requirements repository to interested parties.
  6. The use-case ends.
Specific Requirements
  • [RQ1] XML datastore:Xuse shall use XML as the medium for storing all requirements related information (proposed)
  • [RQ4] Requirements support:Xuse shall support the concept of uniquely identifiable requirements (proposed)
  • [RQ43] Requirements classification:Xuse shall support the classification of requirements for ease of management and to allow for targeted views. (proposed)
  • [RQ44] Requirement type:Xuse shall classify requirements into types. The list of types supported is: functional; non-functional; technical; architectural; constraint and inverse requirement types. (proposed)
  • [RQ45] Requirement package:Xuse shall support classification of requirements into packages. (proposed)
  • [RQ46] Requirement status:Xuse shall support a status held against a requirement. Valid statuses are: proposed, agreed, on-hold, rejected, implemented and validated. Where a requirement has child requirements it will have a composite state - i.e. a composite of all the statuses of the children including children whose state is iteself a composite state. (proposed)
  • [RQ47] Arbitrary requirements classification:Xuse shall support arbitrary classification extensions beyond those explicitly supported. (proposed)
  • [RQ5] Requirements relationships:Xuse shall support parent/child relationships between requirements (proposed)
Activity Diagram