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

Requirements Engineering meets UML Contents What's the point ? What is a requirement ? What is requirements engineering ?

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 2 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 ?

Requirements Engineering meets UML What is a requirement ?

Abbreviations BA= Business Analyst BPL= Business Projektleader ITPL= Information Technology Projektleader

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 5 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.

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 6 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.

Requirements Engineering meets UML What is a requirements engineering ? Overview

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 8 Requirements Engineering Process (BA view) From Requests to Requirements.

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 9 Was ist Anforderung Qualität (Teil I) ? Requirement Quality Checks Effect if not respected … Traceable Requirement CHK_RQA_01Does the Requirement have a unique identifier ? CHK_RQA_02 Is the Requirement Provider known by name and organisational unit for further clarification ? Requirement is useless, since it has no stakeholder. It cannot be clarified in case of ambiguity, and there is no one to accepted it or pay for it. CHK_RQA_03 Is the Requirement traceable to a specific source of business information (e.g. business case/process, use case draft, business concept paper) May be required to prove that the Requirement is based on a group decision or consensus (e.g. WG). Correct Requirement CHK_RQA_04 Is the Requirement expressed in a problem oriented way, i.e. only in terms of what and why, rather than how (problem, not solution oriented)? Implementing solutions with knowing why may lead to better/simpler solutions to the problem being overlooked. Clear Requirement CHK_RQA_05Could the Requirement have more than one interpretation ? Could lead to a solution to the wrong problem being implemented. CHK_RQA_06 Has the (business) Provider's language been used ? IT must adapt to business, and encourages the provider to describe problems rather than solutions CHK_RQA_07 Have the main terms in the Requirement been defined in the glossary ? A lack of common understanding of the key concepts may lead to implementing a solution to the wrong problem. CHK_RQA_08 Does the Requirement contain or refer to sufficient information to allow it be fully understandable ? What is left out, leads to assumptions. These may be wrong. CHK_RQA_09 Are the benefits tangible (Is it possible to prove that the Requirement has been satisfied)? If it can't be measured it can't be managed. CHK_RQA_16 Is the Requirement implementable using the bank's IT infrastructure and standards ? If it can't be implemented it must be outside the scope of an IT project (E.g. fully automatic data quality assurance). CHK_RQA_17 Does the Requirement title summarise the main idea of the Requirement ? You usually don't come back to the requirements in daily cycles. If the title doesn't jog your memory you have to always read the full description every time you come back to the Requirement. This can take a long time if you have more than a couple of Requirements.

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 10 Was ist Anforderung Qualität (Teil II) ? Requirement Quality Checks (continued…) Effect if not respected … Consistent Requirement Set CHK_RQA_10Is the Requirement consistent with the project goals ? Violation of the stated (and budgeted) scope of a project is often one of the factors leading to its failure. CHK_RQA_11 Is the Requirement free from redundancy with already existing Requirements ? Having many requirements that say the same thing in different ways simply wastes the reader's time. CHK_RQA_12 Is the Requirement free from contradiction with already existing Requirements ? The provider must speak with one voice, before IT can process a requirement. CHK_RQA_13 Is the Requirement prioritized ? In the case where resources become tight (or the implementation is excessively expensive) it is essential to know which functionality can be dropped from the current release. CHK_RQA_14 OPTIONAL: Is the Requirement prioritized with respect to the other Requirements ? If all requirements priorities are set to 'high' this is the same as no prioritisation. CHK_RQA_15 Has more than one main idea or issue been expressed in the Requirement (composite Requirement) ? Composite requirements cannot be used as a management instrument to track the progress of a specific functionality through the development process.

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 11 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. 1.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 2.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). 3.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). 4.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). 5.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. 6.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.

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 12 Requirements Engineering Process (BA view) – Details II 7.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. 8.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. 9.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. 10.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). 11.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. 12.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.

t [printed: ____] [saved: 28. August :19 PM] D:\Documents and Settings\t025683\Desktop\Montages\Montages-Presentation.ppt 13 Requirements Engineering Process (BA view) – Details III 13.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. 14.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. 15.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.

Requirements Engineering meets UML What is a requirements engineering ? Active Glossary Management