3 rd                       Unit            Requirements Engineering                   Processes1/24/2009            S.Sree...
Objectives   To describe the principal requirements   engineering activities and their relationships   To introduce techni...
Topics covered   Feasibility studies   Requirements elicitation and analysis   Requirements validation   Requirements mana...
Requirements engineering                   processes   The processes used for RE vary widely   depending on the applicatio...
The requirements engineering process1/24/2009       S.Sreenivasa Rao         5
Requirements engineering1/24/2009            S.Sreenivasa Rao   6
Feasibility studies   A feasibility study decides whether or not   the proposed system is worthwhile.   A short focused st...
Feasibility study implementation   Based on information assessment (what is   required), information collection and report...
Requirement Elicitation and analysis   Sometimes called requirements elicitation or   requirements discovery.   Involves t...
Problems of requirements                   analysis   Stakeholders don’t know what they really want.   Stakeholders expres...
The requirements spiral1/24/2009           S.Sreenivasa Rao   11
Process activities  Requirements discovery   – Interacting with stakeholders to discover their     requirements. Domain re...
Requirements discovery   The process of gathering information about   the proposed and existing systems and   distilling t...
ATM stakeholders   Bank customers   Representatives of other banks   Bank managers   Counter staff   Database administrato...
Viewpoints   Viewpoints are a way of structuring the   requirements to represent the perspectives   of different stakehold...
Types of viewpoint   Interactor viewpoints     – People or other systems that interact directly with the       system. In ...
Viewpoint identification   Identify viewpoints using     – Providers and receivers of system services;     – Systems that ...
LIBSYS viewpoint hierarchy1/24/2009         S.Sreenivasa Rao   18
Interviewing   In formal or informal interviewing, the RE   team puts questions to stakeholders about   the system that th...
Interviews in practice   Normally a mix of closed and open-ended   interviewing.   Interviews are good for getting an over...
Effective interviewers   Interviewers should be open-minded, willing   to listen to stakeholders and should not   have pre...
Requirements validation   Concerned with demonstrating that the   requirements define the system that the   customer reall...
Requirements checking   Validity. Does the system provide the functions   which best support the customer’s needs?   Consi...
Requirements validation                  techniques   Requirements reviews     – Systematic manual analysis of the       r...
Requirements reviews   Regular reviews should be held while the   requirements definition is being formulated.   Both clie...
Review checks   Verifiability. Is the requirement realistically   testable?   Comprehensibility. Is the requirement   prop...
Requirements management   Requirements management is the process of   managing changing requirements during the   requirem...
Requirements change   The priority of requirements from different   viewpoints changes during the development   process.  ...
Requirements evolution1/24/2009           S.Sreenivasa Rao   29
Requirements classification   Requirement                                       Description      Type  Mutable         Req...
Requirements management                    planning   During the requirements engineering process, you   have to plan:    ...
Traceability   Traceability is concerned with the relationships   between requirements, their sources and the   system des...
A traceability matrix    Req.    1.1   1.2   1.3       2.1      2.2   2.3   3.1   3.2    id    1.1           D     R    1....
CASE tool support   Requirements storage     – Requirements should be managed in a secure,       managed data store.   Cha...
Requirements change management   Should apply to all proposed changes to the   requirements.   Principal stages     – Prob...
Change management1/24/2009         S.Sreenivasa Rao   36
3rdUnitSystem models
ObjectivesTo explain why the context of a systemshould be modelled as part of the REprocessTo describe behavioural modelli...
Topics coveredContext modelsBehavioural modelsData modelsObject modelsCASE workbenches
System modellingSystem modelling helps the analyst to understandthe functionality of the system and models areused to comm...
Model typesData processing model showing how the datais processed at different stages.Composition model showing how entiti...
Context modelsContext models are used to illustrate theoperational context of a system - they showwhat lies outside the sy...
The context of an ATM system
Process modelsProcess models show the overall processand the processes that are supported by thesystem.Data flow models ma...
Equipment procurement process
Behavioural modelsBehavioural models are used to describethe overall behaviour of a system.Two types of behavioural model ...
Data-processing modelsData flow diagrams (DFDs) may be used tomodel the system’s data processing.These show the processing...
Order processing DFD
Data flow diagramsDFDs model the system from a functionalperspective.Tracking and documenting how the dataassociated with ...
Insulin pump DFD
State machine modelsThese model the behaviour of the system inresponse to external and internal events.They show the syste...
StatechartsAllow the decomposition of a model intosub-models (see following slide).A brief description of the actions is i...
Microwave oven model
Microwave oven state description     State                                          DescriptionWaiting      The oven is wa...
Microwave oven stimuli    Stimulus                              DescriptionHalf power     The user has pressed the half po...
Microwave oven operation
Semantic data modelsUsed to describe the logical structure of dataprocessed by the system.An entity-relation-attribute mod...
Library semantic model
Data dictionariesData dictionaries are lists of all of the names usedin the system models. Descriptions of the entities,re...
Data dictionary entries   Name                           Description                        Type       Date             De...
Object modelsObject models describe the system in terms ofobject classes and their associations.An object class is an abst...
Object modelsNatural ways of reflecting the real-worldentities manipulated by the systemMore abstract entities are more di...
Inheritance modelsOrganise the domain object classes into ahierarchy.Classes at the top of the hierarchy reflect thecommon...
Object models and the UMLThe UML is a standard representation devised bythe developers of widely used object-orientedanaly...
Library class hierarchy
User class hierarchy
Multiple inheritanceRather than inheriting the attributes and servicesfrom a single parent class, a system whichsupports m...
Multiple inheritance
Object aggregationAn aggregation model shows how classesthat are collections are composed of otherclasses.Aggregation mode...
Object aggregation
Object behaviour modellingA behavioural model shows the interactionsbetween objects to produce some particularsystem behav...
Issue of electronic items
Structured methodsStructured methods incorporate systemmodelling as an inherent part of the method.Methods define a set of...
Method weaknessesThey do not model non-functional systemrequirements.They do not usually include informationabout whether ...
CASE workbenchesA coherent set of tools that is designed tosupport related software process activitiessuch as analysis, de...
An analysis and design     workbench
Analysis workbench componentsDiagram editorsModel analysis and checking toolsRepository and associated query languageData ...
Key pointsA model is an abstract system view.Complementary types of model providedifferent system information.Context mode...
Key pointsSemantic data models describe the logicalstructure of data which is imported to orexported by the systems.Object...
Upcoming SlideShare
Loading in …5
×

Unit 3 requirements engineering processes merged

922 views

Published on

Published in: Technology, Business
  • Be the first to comment

Unit 3 requirements engineering processes merged

  1. 1. 3 rd Unit Requirements Engineering Processes1/24/2009 S.Sreenivasa Rao 1
  2. 2. Objectives To describe the principal requirements engineering activities and their relationships To introduce techniques for requirements elicitation and analysis To describe requirements validation and the role of requirements reviews To discuss the role of requirements management in support of other requirements engineering processes1/24/2009 S.Sreenivasa Rao 2
  3. 3. Topics covered Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management1/24/2009 S.Sreenivasa Rao 3
  4. 4. Requirements engineering processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. However, there are a number of generic activities common to all processes – Requirements elicitation; – Requirements analysis; – Requirements validation; – Requirements management.1/24/2009 S.Sreenivasa Rao 4
  5. 5. The requirements engineering process1/24/2009 S.Sreenivasa Rao 5
  6. 6. Requirements engineering1/24/2009 S.Sreenivasa Rao 6
  7. 7. Feasibility studies A feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks – If the system contributes to organisational objectives; – If the system can be engineered using current technology and within budget; – If the system can be integrated with other systems that are used.1/24/2009 S.Sreenivasa Rao 7
  8. 8. Feasibility study implementation Based on information assessment (what is required), information collection and report writing. Questions for people in the organisation – What if the system wasn’t implemented? – What are current process problems? – How will the proposed system help? – What will be the integration problems? – Is new technology needed? What skills? – What facilities must be supported by the proposed system?1/24/2009 S.Sreenivasa Rao 8
  9. 9. Requirement Elicitation and analysis Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.1/24/2009 S.Sreenivasa Rao 9
  10. 10. Problems of requirements analysis Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change.1/24/2009 S.Sreenivasa Rao 10
  11. 11. The requirements spiral1/24/2009 S.Sreenivasa Rao 11
  12. 12. Process activities Requirements discovery – Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. Requirements classification and organisation – Groups related requirements and organises them into coherent clusters. Prioritisation and negotiation – Prioritising requirements and resolving requirements conflicts. Requirements documentation – Requirements are documented and input into the next1/24/2009round of the spiral. S.Sreenivasa Rao 12
  13. 13. Requirements discovery The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Sources of information include documentation, system stakeholders and the specifications of similar systems.1/24/2009 S.Sreenivasa Rao 13
  14. 14. ATM stakeholders Bank customers Representatives of other banks Bank managers Counter staff Database administrators Security managers Marketing department Hardware and software maintenance engineers Banking regulators1/24/2009 S.Sreenivasa Rao 14
  15. 15. Viewpoints Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyse system requirements.1/24/2009 S.Sreenivasa Rao 15
  16. 16. Types of viewpoint Interactor viewpoints – People or other systems that interact directly with the system. In an ATM, the customer’s and the account database are interactor VPs. Indirect viewpoints – Stakeholders who do not use the system themselves but who influence the requirements. In an ATM, management and security staff are indirect viewpoints. Domain viewpoints – Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standards for inter-bank communications.1/24/2009 S.Sreenivasa Rao 16
  17. 17. Viewpoint identification Identify viewpoints using – Providers and receivers of system services; – Systems that interact directly with the system being specified; – Regulations and standards; – Sources of business and non-functional requirements. – Engineers who have to develop and maintain the system; – Marketing and other business viewpoints.1/24/2009 S.Sreenivasa Rao 17
  18. 18. LIBSYS viewpoint hierarchy1/24/2009 S.Sreenivasa Rao 18
  19. 19. Interviewing In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. There are two types of interview – Closed interviews where a pre-defined set of questions are answered. – Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.1/24/2009 S.Sreenivasa Rao 19
  20. 20. Interviews in practice Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. Interviews are not good for understanding domain requirements – Requirements engineers cannot understand specific domain terminology; – Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.1/24/2009 S.Sreenivasa Rao 20
  21. 21. Effective interviewers Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements. They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.1/24/2009 S.Sreenivasa Rao 21
  22. 22. Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important – Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.1/24/2009 S.Sreenivasa Rao 22
  23. 23. Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked?1/24/2009 S.Sreenivasa Rao 23
  24. 24. Requirements validation techniques Requirements reviews – Systematic manual analysis of the requirements. Prototyping – Using an executable model of the system to check requirements. Covered in Chapter 17. Test-case generation – Developing tests for requirements to check testability.1/24/2009 S.Sreenivasa Rao 24
  25. 25. Requirements reviews Regular reviews should be held while the requirements definition is being formulated. Both client and contractor staff should be involved in reviews. Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.1/24/2009 S.Sreenivasa Rao 25
  26. 26. Review checks Verifiability. Is the requirement realistically testable? Comprehensibility. Is the requirement properly understood? Traceability. Is the origin of the requirement clearly stated? Adaptability. Can the requirement be changed without a large impact on other requirements?1/24/2009 S.Sreenivasa Rao 26
  27. 27. Requirements management Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirements are inevitably incomplete and inconsistent – New requirements emerge during the process as business needs change and a better understanding of the system is developed; – Different viewpoints have different requirements and these are often contradictory.1/24/2009 S.Sreenivasa Rao 27
  28. 28. Requirements change The priority of requirements from different viewpoints changes during the development process. System customers may specify requirements from a business perspective that conflict with end-user requirements. The business and technical environment of the system changes during its development.1/24/2009 S.Sreenivasa Rao 28
  29. 29. Requirements evolution1/24/2009 S.Sreenivasa Rao 29
  30. 30. Requirements classification Requirement Description Type Mutable Requirements that change because of changes to the environment in which the requirements organisation is operating. For example, in hospital systems, the funding of patient care may change and thus require different treatment information to be collected. Emergent Requirements that emerge as the customers understanding of the system develops requirements during the system development. The design process may reveal new emergent requirements. Consequential Requirements that result from the introduction of the computer system. Introducing requirements the computer system may change the organisations processes and open up new ways of working which generate new system requirements Compatibility Requirements that depend on the particular systems or b usiness processes within an requirements organisation. As these change, the compatibility requirements on the commissioned or delivered system may also have to evolve.1/24/2009 S.Sreenivasa Rao 30
  31. 31. Requirements management planning During the requirements engineering process, you have to plan: – Requirements identification How requirements are individually identified; – A change management process The process followed when analysing a requirements change; – Traceability policies The amount of information about requirements relationships that is maintained; – CASE tool support The tool support required to help manage requirements change;1/24/2009 S.Sreenivasa Rao 31
  32. 32. Traceability Traceability is concerned with the relationships between requirements, their sources and the system design Source traceability – Links from requirements to stakeholders who proposed these requirements; Requirements traceability – Links between dependent requirements; Design traceability – Links from the requirements to the design;1/24/2009 S.Sreenivasa Rao 32
  33. 33. A traceability matrix Req. 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 id 1.1 D R 1.2 D D D 1.3 R R 2.1 R D D 2.2 D 2.3 R D 3.1 R 3.2 R1/24/2009 S.Sreenivasa Rao 33
  34. 34. CASE tool support Requirements storage – Requirements should be managed in a secure, managed data store. Change management – The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated. Traceability management – Automated retrieval of the links between requirements.1/24/2009 S.Sreenivasa Rao 34
  35. 35. Requirements change management Should apply to all proposed changes to the requirements. Principal stages – Problem analysis. Discuss requirements problem and propose change; – Change analysis and costing. Assess effects of change on other requirements; – Change implementation. Modify requirements document and other documents to reflect change.1/24/2009 S.Sreenivasa Rao 35
  36. 36. Change management1/24/2009 S.Sreenivasa Rao 36
  37. 37. 3rdUnitSystem models
  38. 38. ObjectivesTo explain why the context of a systemshould be modelled as part of the REprocessTo describe behavioural modelling, datamodelling and object modellingTo introduce some of the notations used inthe Unified Modeling Language (UML)To show how CASE workbenches supportsystem modelling
  39. 39. Topics coveredContext modelsBehavioural modelsData modelsObject modelsCASE workbenches
  40. 40. System modellingSystem modelling helps the analyst to understandthe functionality of the system and models areused to communicate with customers.Different models present the system from differentperspectives– External perspective showing the system’s context or environment;– Behavioural perspective showing the behaviour of the system;– Structural perspective showing the system or data architecture.
  41. 41. Model typesData processing model showing how the datais processed at different stages.Composition model showing how entities arecomposed of other entities.Architectural model showing principal sub-systems.Classification model showing how entitieshave common characteristics.Stimulus/response model showing thesystem’s reaction to events.
  42. 42. Context modelsContext models are used to illustrate theoperational context of a system - they showwhat lies outside the system boundaries.Social and organisational concerns mayaffect the decision on where to positionsystem boundaries.Architectural models show the system andits relationship with other systems.
  43. 43. The context of an ATM system
  44. 44. Process modelsProcess models show the overall processand the processes that are supported by thesystem.Data flow models may be used to show theprocesses and the flow of information fromone process to another.
  45. 45. Equipment procurement process
  46. 46. Behavioural modelsBehavioural models are used to describethe overall behaviour of a system.Two types of behavioural model are:– Data processing models that show how data is processed as it moves through the system;– State machine models that show the systems response to events.These models show different perspectivesso both of them are required to describe thesystem’s behaviour.
  47. 47. Data-processing modelsData flow diagrams (DFDs) may be used tomodel the system’s data processing.These show the processing steps as dataflows through a system.DFDs are an intrinsic part of many analysismethods.Simple and intuitive notation that customerscan understand.Show end-to-end processing of data.
  48. 48. Order processing DFD
  49. 49. Data flow diagramsDFDs model the system from a functionalperspective.Tracking and documenting how the dataassociated with a process is helpful todevelop an overall understanding of thesystem.Data flow diagrams may also be used inshowing the data exchange between asystem and other systems in itsenvironment.
  50. 50. Insulin pump DFD
  51. 51. State machine modelsThese model the behaviour of the system inresponse to external and internal events.They show the system’s responses to stimuli soare often used for modelling real-time systems.State machine models show system states asnodes and events as arcs between these nodes.When an event occurs, the system moves fromone state to another.Statecharts are an integral part of the UML andare used to represent state machine models.
  52. 52. StatechartsAllow the decomposition of a model intosub-models (see following slide).A brief description of the actions is includedfollowing the ‘do’ in each state.Can be complemented by tables describingthe states and the stimuli.
  53. 53. Microwave oven model
  54. 54. Microwave oven state description State DescriptionWaiting The oven is waiting for input. The display shows the current time.Half power The oven power is set to 300 watts. The display shows ŌH powerÕ alf .Full power The oven power is set to 600 watts. The display shows ŌF powerÕ ull .Set time The cooking time is s et to the userÕ input value. The display shows the cooking time s selected and is updated as the time is set.Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ŌN ot readyÕ .Enabled Oven operation is enabled. Interior oven light is off. Display shows Ō Ready to cookÕ .Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for 5 s econds. Oven light is on. Display shows Ō Cooking completeÕ w buzzer is sounding. hile
  55. 55. Microwave oven stimuli Stimulus DescriptionHalf power The user has pressed the half power buttonFull power The user has pressed the full power buttonTimer The user has pressed one of the timer buttonsNumber The user has pressed a numeric keyDoor open The oven door switch is not closedDoor closed The oven door switch is closedStart The user has pressed the start buttonCancel The user has pressed the cancel button
  56. 56. Microwave oven operation
  57. 57. Semantic data modelsUsed to describe the logical structure of dataprocessed by the system.An entity-relation-attribute model sets out theentities in the system, the relationships betweenthese entities and the entity attributesWidely used in database design. Can readily beimplemented using relational databases.No specific notation provided in the UML butobjects and associations can be used.
  58. 58. Library semantic model
  59. 59. Data dictionariesData dictionaries are lists of all of the names usedin the system models. Descriptions of the entities,relationships and attributes are also included.Advantages– Support name management and avoid duplication;– Store of organisational knowledge linking analysis, design and implementation;Many CASE workbenches support datadictionaries.
  60. 60. Data dictionary entries Name Description Type Date Details of the published article that may be ordered byArticle Entity 30.12.2002 people using LIBSYS. The names of the authors of the article who may be dueauthors Attribute 30.12.2002 a share of the fee. The person or organisation that orders a co py of theBuyer Entity 30.12.2002 article. A 1:1 relationship between Article and the Copyrightfee- Relation 29.12.2002 Agency who should be paid the copyright fee.payable-to The address of the buyer. This is used to any paperAddress Attribute 31.12.2002 billing information that is required.(Buyer)
  61. 61. Object modelsObject models describe the system in terms ofobject classes and their associations.An object class is an abstraction over a set ofobjects with common attributes and the services(operations) provided by each object.Various object models may be produced– Inheritance models;– Aggregation models;– Interaction models.
  62. 62. Object modelsNatural ways of reflecting the real-worldentities manipulated by the systemMore abstract entities are more difficult tomodel using this approachObject class identification is recognised as adifficult process requiring a deepunderstanding of the application domainObject classes reflecting domain entities arereusable across systems
  63. 63. Inheritance modelsOrganise the domain object classes into ahierarchy.Classes at the top of the hierarchy reflect thecommon features of all classes.Object classes inherit their attributes and servicesfrom one or more super-classes. these may thenbe specialised as necessary.Class hierarchy design can be a difficult process ifduplication in different branches is to be avoided.
  64. 64. Object models and the UMLThe UML is a standard representation devised bythe developers of widely used object-orientedanalysis and design methods.It has become an effective standard for object-oriented modelling.Notation– Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section;– Relationships between object classes (known as associations) are shown as lines linking objects;– Inheritance is referred to as generalisation and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy.
  65. 65. Library class hierarchy
  66. 66. User class hierarchy
  67. 67. Multiple inheritanceRather than inheriting the attributes and servicesfrom a single parent class, a system whichsupports multiple inheritance allows object classesto inherit from several super-classes.This can lead to semantic conflicts whereattributes/services with the same name in differentsuper-classes have different semantics.Multiple inheritance makes class hierarchyreorganisation more complex.
  68. 68. Multiple inheritance
  69. 69. Object aggregationAn aggregation model shows how classesthat are collections are composed of otherclasses.Aggregation models are similar to the part-ofrelationship in semantic data models.
  70. 70. Object aggregation
  71. 71. Object behaviour modellingA behavioural model shows the interactionsbetween objects to produce some particularsystem behaviour that is specified as a use-case.Sequence diagrams (or collaborationdiagrams) in the UML are used to modelinteraction between objects.
  72. 72. Issue of electronic items
  73. 73. Structured methodsStructured methods incorporate systemmodelling as an inherent part of the method.Methods define a set of models, a processfor deriving these models and rules andguidelines that should apply to the models.CASE tools support system modelling aspart of a structured method.
  74. 74. Method weaknessesThey do not model non-functional systemrequirements.They do not usually include informationabout whether a method is appropriate for agiven problem.The may produce too much documentation.The system models are sometimes toodetailed and difficult for users to understand.
  75. 75. CASE workbenchesA coherent set of tools that is designed tosupport related software process activitiessuch as analysis, design or testing.Analysis and design workbenches supportsystem modelling during both requirementsengineering and system design.These workbenches may support a specificdesign method or may provide support for acreating several different types of systemmodel.
  76. 76. An analysis and design workbench
  77. 77. Analysis workbench componentsDiagram editorsModel analysis and checking toolsRepository and associated query languageData dictionaryReport definition and generation toolsForms definition toolsImport/export translatorsCode generation tools
  78. 78. Key pointsA model is an abstract system view.Complementary types of model providedifferent system information.Context models show the position of asystem in its environment with othersystems and processes.Data flow models may be used to model thedata processing in a system.State machine models model the system’sbehaviour in response to internal or externalevents
  79. 79. Key pointsSemantic data models describe the logicalstructure of data which is imported to orexported by the systems.Object models describe logical systementities, their classification and aggregation.Sequence models show the interactionsbetween actors and the system objects thatthey use.Structured methods provide a framework fordeveloping system models.

×