Fichas
Requirements Engineering
Fichas del conjunto (89)
- 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 - 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 - 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 - 4SDLC Models- Sequential Approach
- Incremental Approach
- Prototype Approach
- Iterative Approach
- Agile Approach - 5Sequential Approach- Phases
- Phase complete, it's not revisited and the deliverables of this phase considered as final
- Phases generally do not overlap - 6Accenture V-Model- possibility to go back
- testlastig
Build Phase:
- Component Test
Test Phase:
- Assembly Test
- Product Test
- Acceptance Test
Deployment:
- Deployment Test - 7Incremental Approach- develop system incrementally
- broken down in sub systems
- high level req. prioritized and split across releases - 8Prototyping Approach- General objectives of sw are known but no detailed req.
- evaluated by user
- iteration takes place as prototype is finetuned - 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 - 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 - 11Agile Approach- built on foundation of iterative appr
- more adaptive on frequent changes
- usually in time crytical appr - 12Agile approach - agile manifesto- Individuals and interactions
- Working software
- Customer collaboration
- Responding to change - 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 - 14Analyze Stage (Custom)- Define Conceptual data model
- Define System Integration flow
- Describe Reports and Batch Processes - 15Global Policy 0011- muss eingehalten werden
- acceptable for projects to tailor or waiver the accenture delivery methods to meet their spec needs - 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 - 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 - 18Why analyze?- req not well defined = solution cannot meet target
- what client want and how the solution to be implemented - 19characteristics: Busines process- Business events
- Product or service
- Resource money, people and computer - 20Analyze Process- Analyze As-Is and To-Be business processes to reach detailed understanding
- 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 - 22Concepts of process modeling- Abstraction
- Grouping/Generalization
- Sub-typing/Specialization - 23Principle of process modeling- highlight important components of current investigation
- creates clarity for analysis and desig - 24What is a process?- series of tasks which must be performed to reach goal
- 25What is Process Modeling- technique which help BA to break down processes into activities, tasks
- 26Process Model components- Activity
- Business Event
- Entities
- Process
- Task
- Workflow diagram - 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 - 28Defining common terms- defining project glossary
- reducing misunderstandings
- extract key concepts from high level req - 29SMART- Specific
- Measurable
- Attainable
- Realisable
- Traceable
Escape clause - 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 - 31Requiremet gathering techniques- Focus Group
- Joint Application Design (JAD) Session
- Intervies (with user)
- Scenario/visualisation - 32Requirements gathering tools- Process flow
- Use cases
- Diagrammign
- Prototypes
- Reverse engineering - 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 - 34Prototypes- most appropriate with user and stakeholder
- illustration with UI or mockups
- user can see UI - 35Prototype techniques- Fidelities (Low, High)
- Degree of Interaction
- Used for interface prototyping - 36Importance of Requirements Management- Meeting project deadlines
- Maintaining a project scope
- Promoting communication
- Satisfying customer needs
*Lowering costs and requirements errors - 37What is a Model?Representation of Requirements
- 38Why is Req. Modeling used?- create functional abstraction of system
- visualize the proposed system
- identify gaps - 39Event Model- External Events
- Internal Events
- Temporal Events
Model:
- Event
- trigger
- source - 40Process Model- Business Process
- Input, Output
- Data Processing - 41Data Model- Entity
-- Entity Type
--- Entity Type Occurance
- Relationships
Bsp. Class Diagram - 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 - 43Prozessmodelle- Business Process Model
- Activity Diagram
- Process Decomposition - 44ADM bevorzugte modellierungEntity Relationship Model
- 45Why Decomposition?- Increase manageability of process models
- Easy to combine across processes - 46Modeling (Diagrams)- Class Diagram
- Sequence Diagram
- Use Case Diagram
- Activity Diagram - 47Use Case Model contains- Use Case Diagram
- Use Case description - 48Use Case Model isAn analysis tool that describes an applications functional requirements
- 49Use Case: Characteristics- Iterative
- Graphical and Textual
- Based on pre-defined scope
- Focused on "What"
- User-centric
- Flow and function based - 50Use Case Diagram Components- Actor
- Use Case
- Association
- System Boundary - 51How to identify Use Cases?- Functional Requirements
- Business Process Design
- Solution Planning Deliverables
- Project Glossary - 52Describe Pre-Conditions- Always mandatory if exist
- Never checked again by the system within the use case
- Identical for all Use case flows - 53Describe Triggers- there may be more than one trigger for one use case, should all be listed
- 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 - 55Consolidate Use Cases- Combine similar Use cases
- Extract common behaviour (include)
- Extract Optional Behaviour (extend) - 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 - 57Entity Relationship Model components- Entity
- Entity Type
- Entity Type Occurance
- Attribute Type
- Relationship - 58State diagram components- States
- Events
- Transitions - 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 - 60Steps of Requirements Management- Base Line the requirements
- validate the requirements
- Control changes - 61Two distinct areas of Scope Management- Project Scope
- Product Scope - 62Benefits of Scope Management- Define requirements
- reduced risks
- reduced costs - 63Change Control Tasks- Baseline requirements
- Review change request
- Asses impact of change request
- Determine decision
- Implement decision - 64Change Request is a- material change (modification) to a commitment that was agreed by client and engagement leadership
- 65Material changes- project scope
- release schedule
- acceptance criteria
- method of delivery
- service level metrics or method of measurement
- quality
- performance - 66What is Requirements Traceability?- One way of maintaining documentation
- Demonstrates a clear connection between the captured requirement and is corresponding developed artifacts - 67Metrics Examples- Requirements Volatility
- Peer review effectiveness
- Project End Date Variance - 68RACI- Responsible
- Accountable
- Consulted
- Informed - 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(Prioritization Dimension - Requirements Driven)- Harm avoidance
- Risk
- Requirements stability
- Requirements dependencies
- Implementation dependencies
- Requirement type - 71Prioritization Dimension - Business Driven- Business value
- Cost
- Difficulty
- Time to market
- Legal mandate
- Frequency
- Re-use - 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. - 73Peer reviews help increase- Content
- Compliance with standards and formats
- Quality of work products
- Client satisfaction
- Knowledge transfer and continuous improvement - 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 - 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 - 76Hi-fi prototypes- detailed GUI
- matches look and feel
- reduce project risk - 77Why should we use Prototypes?Prototyping helps reducing project risk
- 78Prototyping risks- stakeholder thinks product is complete
- user fixed on how instead of what
- user infer performance from prototype in final product - 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 - 80What are Transition Points?logical point deliverable tansitioned from one team to another & from 1 phase to another
- 81The main purposes of the transition points are- Ensure the quality of deliverables
- Foster effective communication - 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 - 83Confirm and Transition Application Analysis Deliverables- Identify Components and Classes
- Design Readiness
- Finalize Changes and Revise Application Design Estimates - 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) - 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 - 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 - 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 - 88Peer Review Types- Requirements Review
- General Design Review
- Detailed Design Review
- Code Review
- Testing Review
- Training Review - 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
Información
- Descripción
- Fichas sobre Requirements Engineering, creado por Cihan Hasanoglu el 26/04/2018.
- Creado por
- Cihan Hasanoglu · abr 2018
- Actualizado
- 26 abr 2018
- Visitas
- 10
- Valoración