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