Requirements engineering iv

553 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
553
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • SA centered upon modeling the pre-existing system. PDOA based its approached around problem frames. It appears to rest on a more secure foundation, helps identify weakness in the others and may well prove to be the way ahead.
  • Lack: Behaviour of the system: state, The technique for Idesign itself, i.e. functional decomposition is still questionable Applications that are not suit SA are: Non-existing system Complex and large pre-existing system: Real-time problem domain, controller system
  • Lack: Behaviour of the system: state, The technique for Idesign itself, i.e. functional decomposition is still questionable Applications that suit SA are: Non-existing system Complex and large pre-existing system: Real-time problem domain, controller system
  • Lack: Behaviour of the system: state, The technique for Idesign itself, i.e. functional decomposition is still questionable Applications that suit SA are: Non-existing system Complex and large pre-existing system: Real-time problem domain, controller system
  • Problem frames model the problem domain as a set of inter-related sub-domains, where a sub–domain (often shorten to ‘domain’) is any part of the problem domain that may be usefully signled out Less prescriptive, procedure: Collect basic information and develop problem frame(s) in order to establish the type of the problem domain Guided by the problem frame(s), collect further detail and develop description of the relevant characteristics of the problem domain In conjunction with the foregoing, collect and document the requirements for the new system
  • Problem frames model the problem domain as a set of inter-related sub-domains, where a sub–domain (often shorten to ‘domain’) is any part of the problem domain that may be usefully signled out Less prescriptive, procedure: Collect basic information and develop problem frame(s) in order to establish the type of the problem domain Guided by the problem frame(s), collect further detail and develop description of the relevant characteristics of the problem domain In conjunction with the foregoing, collect and document the requirements for the new system
  • Requirements engineering iv

    1. 1. Requirements Engineering Indri Sudanawati Rozas April 2012
    2. 2. Activities?Feasibility Requirements study elicitation and analysis Requirements specificationFeasibility Requirements report validation System models U and system ser requirements Requirements document
    3. 3. Requirements 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 stakeholders: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.
    4. 4. Requirements Analysis• Acquire understanding about the problem domain characteristics and problem to find the solution• It is an information-acquiring, -collating, and –structuring process through which one attempts to understand all the various parts of a problem and their relationships.• Basic Issues: – How to effectively elicit a complete set of requirements from the customer or other sources? – How to decompose the problem into intellectually manageable pieces? – How to organize the information so it can be understood? – How to communicate about the problem with all the parties involved? – How to resolve conflicting needs? – Ho to know when to stop?
    5. 5. Analysis PrinciplesEach analysis method has a unique point of view.All analysis methods are related by a set of operational principles:• represent and understand the information domain• define the functions that the software• represent the behavior of the software• use models to depict information, function, and behavior --> uncover the details in a layered fashion.• move from essential information toward to detailsA set of guidelines for requirement engineering:•understand the problem before beginning to create the analysis model•develop prototypes to help user to understand how human-machineinteractions•record the origin of and the reasons for every requirement•use multiple views of requirements•prioritize requirements• work to eliminate ambiguity
    6. 6. The Information Domain• Software is built to process data, to transform data from one form to another.• Software also process events.• The first operational analysis principle requires to exam the information domain.• Information domain contains three different views of the data and control: – information content and relationship: information content --> represent the individual data and control objects – information flow: represents the manner in which data and control change as each moves through a system. Data and control moves between two transformations (functions) – information structure: represent the internal organization of various data and control items • data tree structure • data table (n-dimension)
    7. 7. The requirements analysis process Requirements definition and Requirem ents specification validati on Domain Prioritization understandingProcess entry Requirements Conflict collection resolution Classification
    8. 8. System models• Different models may be produced during the requirements analysis activity• Requirements analysis may involve three structuring activities which result in these different models – Partitioning. Identifies the structural (part-of) relationships between entities – Abstraction. Identifies generalities among entities – Projection. Identifies different ways of looking at a problem• Using modeling techniques, e.g. UML
    9. 9. System Requirements Analysis Consideration http://www.cio.ny.gov/pmmp/guidebook2/SystemReq.pdf
    10. 10. Requirements AnalysisFundamental Techniques (Views)• functional view – hierarchy - function tree – process  use cases – information ow  data flow diagram (DFD)• data oriented view – data structures  data dictionary (DD), syntax diagram, Jackson diagram – relations between entities  entity relationship diagram (ER)• object-oriented view – class structure  class diagram• algorithmic view – control structures – pseudo code, structogram, flow diagram, Jackson diagram – conditions  rules, decision table• state-oriented view – state machines – Petri nets – sequence charts
    11. 11. Methods for Requirements Analysis1. Structured Analysis2. Object Oriented Analysis3. Problem Domain Oriented Analysis4. Viewpoint Oriented Analysis
    12. 12. 1. Structured Analysis• Centered upon modeling the pre-existing system – Process – Data flow – Structure of data stored• Weakness: – Downplay the study of the problem domain – Requirements are specified in term of design – Lack of sharp boundary between analysis and design encourage premature design – Functional specification is absent – Ill-suited for certain (not rarely) types of application
    13. 13. 2. Object Oriented Analysis• It’s not really an analysis: – It requires pre-existing requirements document and behaviour specification.• High-level, architectural, design of the solution system.• OOA Outline: – Identify object classes within the problem domain – Define the attribute and methods of those classes – Define the behaviour of those classses – Model the relationships between those classes
    14. 14. 2. Object Oriented Analysis• Three perspective of class model – Specification (i.e. interface classes) – Conceptual (i.e. problem domain classes – related to analysis) – Implementation (i.e. related to internal design)
    15. 15. 3. Problem Domain Oriented Analysis• Centered on modeling the problem context – Problem frames: capture significantly more information about the problem domain• Less modeling, more description, procedure: – Collect basic information and develop problem frame(s) to establish the type of the problem domain – Collect further detail and develop description of the relevant characteristics of the problem domain – Collect and document the requirements for the new system
    16. 16. 3. Problem Domain Oriented Analysis• Type of problem domain: – Workpiece system – perform directed operations upon objects that exist only within the system – Control system – control the behavior (required- commanded) of part of the problem domain – Information system – provide information (automatically- responsively) about the problem domain – Transformation system – transform input data in a particular format into output data in a corresponding, particular format – Connection system – maintain correspondence between sub-domains that are not directly connected
    17. 17. 4. Viewpoint-oriented analysis• Stakeholders represent different ways of looking at a problem or problem viewpoints – different types of stakeholders – different views among stakeholders of same type• This multi-perspective analysis is important as there is no single correct way to analyse system requirements
    18. 18. Multiple problem viewpoints Problem to be analysed
    19. 19. Requirements vs. Design Requirements DesignDescribe what will be delivered Describe how it will be donePrimary goal of analysis: Primary goal of design:UNDERSTANDING OPTIMIZATIONThere is more than one solution There is only one (final) solutionCustomer interested Customer not interested (Most of the time) except for external

    ×