Requirements Engineering meets UML

1
Requirements Engineering meets UML
Richard Farr, Cybernetic Intelligence GmbH
1st. September 2007
2
Requirements Engineering meets UMLContents

• What's the point ?
• What is a requirement ?
• What is requirements engineering ?

3
What's the point ?

• Is requirements engineering a way to get UML
  modeling acceptance ?
• Can requirements engineering deliverables seed
  UML modelling ?
• Does requirements engineering provide a way of
  managing the development process ?

4
Requirements Engineering meets UMLWhat is a
requirement ?
5

• AbbreviationsBA Business Analyst
• BPL Business Projektleader
• ITPL Information Technology Projektleader

6
What is a Requirement (a definition) ?

• A requirement documents the result of a common
  process between business and IT to fully
  understand a problem that IT will solve for
  business, at a given point in time.

7
What is a Requirement (its properties) ?

• The main properties of a requirement are
• Content (Semantic) that belongs to business and
  must have a (named) business owner and be
  traceable back to an originating document.
• Form (Syntax) that belongs to a (named) BA, who
  is responsible for driving the requirements
  analysis process and ensuring its quality.
• Requirements Status has a shared responsibility
  and simply shows the progress of the requirement
  through the process
• status 'Incomplete' holds until the BA is
  satisfied with the quality of the requirement,
  then sets it to 'Submitted'.
• status 'Accepted' once the BPL and ITPL have
  reached a common understanding of the problem,
  and the ITPL has agreed to propose one or more
  solutions (IT) for a give release date. From this
  point onwards the requirement is frozen. Any
  further changes are subject to evaluation by the
  change control board .
• status various. IT Stati belonging to the IT
  develeopment process.
• status 'Closed' is the responisbilty of the
  business owner. Will be set once the requirement
  has been satisfied by It deliverying an
  application, or business withdrawing the
  requirement.

8
Requirements Engineering meets UMLWhat is a
requirements engineering ?

• Overview

9
Requirements Engineering Process (BA view)
From Requests to Requirements.
10
Was ist Anforderung Qualität (Teil I) ?
11
Was ist Anforderung Qualität (Teil II) ?
12
Requirements Engineering Process (BA view)
Details I

• The picture in Slide 8 shows what happens to a
  Request during its lifecycle. The steps are
  organised in order of importance. For example, if
  the traceability information is missing, then
  there is no point in going any further. Therefore
  this is the first aspect that is checked in the
  process listed below.
• A Request can be submitted by people occupying
  any of the following roles BPL, ITPL, Architect
  and xxx. The Request can be based on any suitable
  source of information, including Use Case
  Drafts, xxx
• Upon receiving the Request, this is checked for
  traceability. This means that the Requirement
  Provider must be identified by first last name
  organisational unit. It is also desirable to
  provide a link to the principle source of
  information for this request. If this information
  is missing, it is essential to go back to the
  provider (if this is known) and complete the
  missing data. If this information is not
  available, then this request must be deleted from
  the requirement engineering repository (this is
  the only case where requests are actually
  deleted, rather than being frozen or archived).
• This and the following two steps represent the
  main glossary work. This step requires that the
  terms that already exist in the glossary, and
  apply to this request are found. These found
  glossary terms are now checked to see if they
  apply in the context of this request (E.g. the
  word account is found in both the glossary and
  in the description of the request being examined.
  However the request deals with a type of banking
  product, whereas the glossary describes an user
  account used in an It system. Clearly the context
  is not the same, and the existing glossary term
  does not apply).
• Glossary terms are sometimes found in the
  request, but did not apply. Alternatively a term
  can be found in the request, which needs further
  definition, but not in the glossary. In both
  these cases a new term must be added to the
  glossary, and linked to the current request.
  (E.g. continuing the example above, the term
  account must be added to the glossary, but
  classified in the domain called banking. This
  new term must now be linked to the request).
• A more extreme case is where the major part of
  the request is in fact the definition of a
  business term, or its structure. In this case one
  or more glossary terms must be created, with a
  link to this request as its originating document.
  If this request contains only glossary
  information, it is removed from the set of
  requests being processed and archived. If this
  request contains more than just glossary
  information, then continue the processing.
• Now that the request has been sufficiently
  defined by glossary terms, it is now possible to
  evaluate whether this request is ambiguous. This
  may be the case if either the Request has more
  than one interpretation, or if it is not defined
  in sufficient detail to provide a clear idea of
  the problem to be solved. If this is the case, it
  is essential to go back to the provider and
  obtain the missing information. Once this
  information has been obtained, and the request
  has been modified, processing must be resumed
  from step 3. listed above. If this information
  cannot be obtained within a reasonable timeframe,
  then this request is removed from the set of
  requests being processed and archived.

13
Requirements Engineering Process (BA view)
Details II

• Goals must have been set at program or project
  levels. These can be considered as super- or top
  level requests. The request being processed must
  be mapped to at least one of these goals. If this
  is not possible the request may be outside the
  scope of the project or the program. In this
  case, and if the request is of a medium or high
  priority, then it may be useful to ensure that a
  goal is not missing. If this mapping cannot be
  obtained within a reasonable timeframe, then this
  request is removed from the set of requests being
  processed and archived.
• The correctness of the request will now be
  checked - is the Request expressed in a problem
  oriented way, i.e. only in terms of what and why,
  rather than how ? If the request only contains
  the definition of a solution, then the nature of
  the problem to be solved must be discovered
  together with the provider. The request must then
  be modified and processing must be resumed from
  step 3. listed above. If this information cannot
  be obtained within a reasonable timeframe, then
  this request is removed from the set of requests
  being processed and archived.
• A clear request is where the Provider's language
  been used. Also the Request Short Description
  must summarise the main idea of the Request,
  acting as a title for the Request. If his is not
  the case, the request must be modified together
  with the provider and processing must be resumed
  from step 3. listed above. If this information
  cannot be obtained within a reasonable timeframe,
  then this request is removed from the set of
  requests being processed and archived.
• The processing of individual requests has now
  been completed, and before a full set of requests
  is considered, this processing point provides a
  final check as to whether the request is actually
  a business request, or whether it must be
  re-classified as an architectural or IT request.
  In this case the request must be evaluated by the
  Architectural office before it is passed on to
  the individual projects. (further processing
  still to be determined xxx).
• Any requests which contain the same idea as
  another request, must be identified. If the no
  new information is contained in this request
  (100 duplicate), then this request is removed
  from the set of requests being processed and
  archived. Where there is some additional
  information (less than 100 duplicate) then this
  request will be processed further.
• Any requests which contain the same idea as
  another request, but is in contradiction with
  this idea, must be identified. If the no new
  information is contained in this request (100
  contradiction), then this request is removed from
  the set of requests being processed and archived.
  Where there is some additional information (less
  than 100 contradiction) then this request will
  be processed further.

14
Requirements Engineering Process (BA view)
Details III

• A request where more than one main idea or issue
  been expressed (composite Request) this request
  must be broken up into sub- requests. This will
  form a structure where the leaves of the
  structure are requests containing only one idea.
  Also, requests which are not 100 duplicates or
  contradictions must also be broken down into a
  structure of sub-requests. This will result in
  new 100 duplicate or contradiction requests
  being identified and mapped to their active
  counterpart. These new 100 duplicate or
  contradiction requests will now be removed from
  the set of requests being processed and archived.
  The parts of the structures, which are not
  duplicates or contradictions, will be added to
  the set of requests being processed.
• At this point the requests are considered to be
  of a sufficient quality that they can be assigned
  to one (or more) projects. Any requests, which
  cannot be assigned, are passed back to program
  level requirements engineering to be re-evaluated
  together with the request provider. If this
  information cannot be obtained within a
  reasonable timeframe, then this request is
  removed from the set of requests being processed
  and archived. A request assigned to one or more
  projects is now called a feature. These features
  are split into requirements, where one
  requirement belongs to no more than one project.
• Any requirements, which cannot be processed by a
  project, are passed back to program level
  requirements engineering to be re-evaluated
  together with the request provider. If this
  information cannot be obtained within a
  reasonable timeframe, then this request is
  removed from the set of requests being processed
  and archived.

15
Requirements Engineering meets UMLWhat is a
requirements engineering ?

• Active Glossary Management