GoConqr hat ein neues Design! Sag uns, wie es dir gefällt.

Kostenlos registrieren

Karteikarten

Requirements Engineering

Cihan Hasanoglu Englisch 89 Karten

Karten in diesem Stapel (89)

  1. 1What are requirements?- Needed to meet business and system needs
    - Condition or capability needed by a user to solve a problem or achieve an objective
    - Functions we expect a system to be able to perform
  2. 2What is a bad requirement?- The relative cost to fix a defect increases as the defect is allowed to propagate through the software lifecycle
    - steigt exponentiell
  3. 3Requirements Engineering Tasks- Confirm gathering requirement
    - Gather requirements
    - Develop and Document requirements
    - Verify Requirements
    - Establish traceability of requirements
    - Review and Prioritize Requirements
    - Obtaign sign-off and Transition
  4. 4SDLC Models- Sequential Approach
    - Incremental Approach
    - Prototype Approach
    - Iterative Approach
    - Agile Approach
  5. 5Sequential Approach- Phases
    - Phase complete, it's not revisited and the deliverables of this phase considered as final
    - Phases generally do not overlap
  6. 6Accenture V-Model- possibility to go back
    - testlastig
    Build Phase:
    - Component Test
    Test Phase:
    - Assembly Test
    - Product Test
    - Acceptance Test
    Deployment:
    - Deployment Test
  7. 7Incremental Approach- develop system incrementally
    - broken down in sub systems
    - high level req. prioritized and split across releases
  8. 8Prototyping Approach- General objectives of sw are known but no detailed req.
    - evaluated by user
    - iteration takes place as prototype is finetuned
  9. 9Iterative Approach- mitigates risks by planning in iterations
    - time may be longer than usually prototyping
    - can be combined with other approaches
    - analysis done same manner as in sequential
    - once prios established iterations are planned
  10. 10Iterative Approach - Spiral Model- Testing is completed in the final delivered iteration
    - stakeholder/ user is alwas in the development lifecycle
    - combined iterative and waterfall approaches
    - requirements not fully known
  11. 11Agile Approach- built on foundation of iterative appr
    - more adaptive on frequent changes
    - usually in time crytical appr
  12. 12Agile approach - agile manifesto- Individuals and interactions
    - Working software
    - Customer collaboration
    - Responding to change
  13. 13Agile Approach - development approaches- Extreme Programming (XP)
    - Crystal Methodologies
    - Scrum
    - Feature-Driven Development (FDD)
    - Adaptive Software Development (ASD)
    - Lean Software Development
    - Accenture Delivery Methods for Distributed Agile
  14. 14Analyze Stage (Custom)- Define Conceptual data model
    - Define System Integration flow
    - Describe Reports and Batch Processes
  15. 15Global Policy 0011- muss eingehalten werden
    - acceptable for projects to tailor or waiver the accenture delivery methods to meet their spec needs
  16. 16What is Solution Planning?- Acc respond to client proposal request by designing one or more solutions/options for client choose
    - Multiple pricing options like shorter timeline, lower cost by increasing delivery center utilization
  17. 17What is Analysis?- System requirements
    - Requirement metrics
    - Business events
    - User scenarios
    - User accessing system
    - process within the system
    - system respond to events
    - information the system needs to manage
  18. 18Why analyze?- req not well defined = solution cannot meet target
    - what client want and how the solution to be implemented
  19. 19characteristics: Busines process- Business events
    - Product or service
    - Resource money, people and computer
  20. 20Analyze Process- Analyze As-Is and To-Be business processes to reach detailed understanding
  21. 21SP044 Current Capability Tools for As-Is- Identify opportunities for improvement
    - Analyzing gaps between req and where they are now
    - Understanding current operations and performance
    - Identifying further requirements
    - Understanding constraints
    - Identifying aspects that add value
    - Identifying aspects that do not add value
    - Identifying weaknesses
  22. 22Concepts of process modeling- Abstraction
    - Grouping/Generalization
    - Sub-typing/Specialization
  23. 23Principle of process modeling- highlight important components of current investigation
    - creates clarity for analysis and desig
  24. 24What is a process?- series of tasks which must be performed to reach goal
  25. 25What is Process Modeling- technique which help BA to break down processes into activities, tasks
  26. 26Process Model components- Activity
    - Business Event
    - Entities
    - Process
    - Task
    - Workflow diagram
  27. 27Business Analysts - Responsibilites- Requirements and Traceability
    - Project glossary
    - Use case diagram and use case scenarios
    - use case
    - business rules
    - report and batch process descriptions
    - business process design
  28. 28Defining common terms- defining project glossary
    - reducing misunderstandings
    - extract key concepts from high level req
  29. 29SMART- Specific
    - Measurable
    - Attainable
    - Realisable
    - Traceable
    Escape clause
  30. 30Business Rules- Statement of fact
    - not a requirement but system has to deal with it
    - maybe a policy of client legacy system
    - no prio everyone is important
  31. 31Requiremet gathering techniques- Focus Group
    - Joint Application Design (JAD) Session
    - Intervies (with user)
    - Scenario/visualisation
  32. 32Requirements gathering tools- Process flow
    - Use cases
    - Diagrammign
    - Prototypes
    - Reverse engineering
  33. 33Scenarios / Visualization- offline processes
    - system not existing replaced by manual offline processes
    - no physical prototype/mockup user not restricted by what they see
    - most successful with only user without stakeholder
  34. 34Prototypes- most appropriate with user and stakeholder
    - illustration with UI or mockups
    - user can see UI
  35. 35Prototype techniques- Fidelities (Low, High)
    - Degree of Interaction
    - Used for interface prototyping
  36. 36Importance of Requirements Management- Meeting project deadlines
    - Maintaining a project scope
    - Promoting communication
    - Satisfying customer needs
    *Lowering costs and requirements errors
  37. 37What is a Model?Representation of Requirements
  38. 38Why is Req. Modeling used?- create functional abstraction of system
    - visualize the proposed system
    - identify gaps
  39. 39Event Model- External Events
    - Internal Events
    - Temporal Events
    Model:
    - Event
    - trigger
    - source
  40. 40Process Model- Business Process
    - Input, Output
    - Data Processing
  41. 41Data Model- Entity
    -- Entity Type
    --- Entity Type Occurance
    - Relationships
    Bsp. Class Diagram
  42. 42Importance of Event Modeling- Helps establish the scope
    - Define the events
    - Helps identify the data
    - Can be used along with the data model and process model
  43. 43Prozessmodelle- Business Process Model
    - Activity Diagram
    - Process Decomposition
  44. 44ADM bevorzugte modellierungEntity Relationship Model
  45. 45Why Decomposition?- Increase manageability of process models
    - Easy to combine across processes
  46. 46Modeling (Diagrams)- Class Diagram
    - Sequence Diagram
    - Use Case Diagram
    - Activity Diagram
  47. 47Use Case Model contains- Use Case Diagram
    - Use Case description
  48. 48Use Case Model isAn analysis tool that describes an applications functional requirements
  49. 49Use Case: Characteristics- Iterative
    - Graphical and Textual
    - Based on pre-defined scope
    - Focused on "What"
    - User-centric
    - Flow and function based
  50. 50Use Case Diagram Components- Actor
    - Use Case
    - Association
    - System Boundary
  51. 51How to identify Use Cases?- Functional Requirements
    - Business Process Design
    - Solution Planning Deliverables
    - Project Glossary
  52. 52Describe Pre-Conditions- Always mandatory if exist
    - Never checked again by the system within the use case
    - Identical for all Use case flows
  53. 53Describe Triggers- there may be more than one trigger for one use case, should all be listed
  54. 54Describe Post-Conditions- A post-condition also describes the "possible states" the system can be in after a use case has finished
    - Alternative flows are likely to have separate post-conditions
  55. 55Consolidate Use Cases- Combine similar Use cases
    - Extract common behaviour (include)
    - Extract Optional Behaviour (extend)
  56. 56How is an Entity Relationship Model Used?- describes entities in system & the relationships
    - type of conceptual entity
    - is ADM recommended approach for creating a data model
  57. 57Entity Relationship Model components- Entity
    - Entity Type
    - Entity Type Occurance
    - Attribute Type
    - Relationship
  58. 58State diagram components- States
    - Events
    - Transitions
  59. 59What is a state diagram?- specifies sequence of states that an object goes through in response to events
    - shows one or more possible transitions triggered by an event
    - Shows how the state of an object or the system changes as event occur
  60. 60Steps of Requirements Management- Base Line the requirements
    - validate the requirements
    - Control changes
  61. 61Two distinct areas of Scope Management- Project Scope
    - Product Scope
  62. 62Benefits of Scope Management- Define requirements
    - reduced risks
    - reduced costs
  63. 63Change Control Tasks- Baseline requirements
    - Review change request
    - Asses impact of change request
    - Determine decision
    - Implement decision
  64. 64Change Request is a- material change (modification) to a commitment that was agreed by client and engagement leadership
  65. 65Material changes- project scope
    - release schedule
    - acceptance criteria
    - method of delivery
    - service level metrics or method of measurement
    - quality
    - performance
  66. 66What is Requirements Traceability?- One way of maintaining documentation
    - Demonstrates a clear connection between the captured requirement and is corresponding developed artifacts
  67. 67Metrics Examples- Requirements Volatility
    - Peer review effectiveness
    - Project End Date Variance
  68. 68RACI- Responsible
    - Accountable
    - Consulted
    - Informed
  69. 69Challenges in General- Large number of requirements
    - Limited resources
    - Quality requirements
    - Goals versus requirements
    - Changing priorities
    - Incompatible priorities
    - Incompatible requirements
    - Lack of trust
    - Non-requirements
  70. 70(Prioritization Dimension - Requirements Driven)- Harm avoidance
    - Risk
    - Requirements stability
    - Requirements dependencies
    - Implementation dependencies
    - Requirement type
  71. 71Prioritization Dimension - Business Driven- Business value
    - Cost
    - Difficulty
    - Time to market
    - Legal mandate
    - Frequency
    - Re-use
  72. 72What is a Peer Review?Peer reviews are quality-of a product, conducted by others on the project, to identify problems and
    areas where changes are needed.
  73. 73Peer reviews help increase- Content
    - Compliance with standards and formats
    - Quality of work products
    - Client satisfaction
    - Knowledge transfer and continuous improvement
  74. 74Peer review help decrease- Problems or errors in deliverables eraly in the process
    - Number of change requests
    - Additional time resulting from rework
    - Additional costs resulting from rework
  75. 75Low-fi prototyping- Engages non-programmers in the idea crystallization process
    - Easily modified between requirements sessions
    - Saves money, fast, and often serves the purpose
    - Facilitates rapid iteration
  76. 76Hi-fi prototypes- detailed GUI
    - matches look and feel
    - reduce project risk
  77. 77Why should we use Prototypes?Prototyping helps reducing project risk
  78. 78Prototyping risks- stakeholder thinks product is complete
    - user fixed on how instead of what
    - user infer performance from prototype in final product
  79. 79Prototyping success factors are- prototyping tasks in project plan
    - State the purpose of each prototype before you built it
    - plan to develop multiple prototypes
    - Use plausible data
  80. 80What are Transition Points?logical point deliverable tansitioned from one team to another & from 1 phase to another
  81. 81The main purposes of the transition points are- Ensure the quality of deliverables
    - Foster effective communication
  82. 82Importance of Transition Points- Team Communication & interaction @ key points during life cycle
    - Critical to minimize miscommunications
    - allow projects to move from 1 stage to next & also potentially to a different site
  83. 83Confirm and Transition Application Analysis Deliverables- Identify Components and Classes
    - Design Readiness
    - Finalize Changes and Revise Application Design Estimates
  84. 84Identify Components and Classes- Perform use case realization to identify components and classes.
    - Use the conceptual data model to drive out the domain class model Identify
    - (Entwickler schaut ob er mit unseren Modellierungen etwas anfangen kann)
  85. 85Design Readiness- Start Application Design to verify Readiness
    - fix gaps
    - start application design select use cases to verify that use cases and other associated analysis deliverables are sufficiently detailed
  86. 86Finalize Changes and Revise Application Design Estimates- design team should revisit initial effort estimates to ensure accuracy
    - design team should review the work plan for design and verify that timeline & resource plans are valid & achievable
    - Work closely with the project manager to update estimates and work plan as appropriat
  87. 87Reviews and Sign-Off with Project Sponsors- ONLY project sponsor can sign-off & agree that current phase is completed
    - Sign-off must be written or electronic form
    - Formal review and sign-off with project sponsor occurs at the completion of each stage of work
    -- Client governance processes may cause complexity
  88. 88Peer Review Types- Requirements Review
    - General Design Review
    - Detailed Design Review
    - Code Review
    - Testing Review
    - Training Review
  89. 89What is Verification, Prioritization and Validation?- Analyzing Requirements involves prioritization, verification and validation
    - Prio, verif, vali processes work in parallel & are not necessarily implemented sequentially
    - Prio, verif, vali are typically accomplished in multiple iterations throughout Plan & Analyze stages & continue throughout the system lifecycle

Informationen

Beschreibung
Karteikarten am Requirements Engineering, erstellt von Cihan Hasanoglu am 26/04/2018.
Erstellt von
Cihan Hasanoglu · Apr 2018
Aktualisiert
26 Apr 2018
Aufrufe
10
Bewertung

Feedback

Worum geht es?

Wie gefällt dir das neue Design?

Dein Eindruck