Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
Requirements based
Contracting, based on requirements elicitation
| Question | Answer |
|---|---|
| Contracting party activities | Problem domain – Do inception and the first iteration(s) in elaboration – Create Use Case model and develop the use case model during the whole process |
| Contracted party activities | Solution domain – Do the rest – Will define the architecture of the system |
| Contracting party arifacts | Requirements 1) Vision 2) Use Case Model 3) Supplementary Specifications 4) Glossary 5) Requirement Management Plan 6) Requirement Attribute 7) Domain Model (optional) Analysis 8) Analysis Model |
| Analysis model | 1) functional model 2) analysis object model 3) dynamic model |
| Functional model | 1) Use cases 2) Scenarios |
| Analysis object model | 1) Class and 2) object diagrams with operations, relationships |
| Dynamic model | 1) State machine 2) Sequence diagram focusing on the behavior of the system |
| Object types | 1) Boundary Objects 2) Control Objects 3) Entity Objects |
| Contracted party artifects | Analysis 1) Software Architecture Document 2) Design Model 3) Data Model 4) Deployment Model 5) UI / Navigation Map Implementation 6) Implementation Mondel 7) Integration Build Plan |
| Use case in the sense of requirements based contracting | – Functional requirements – Defines the scope of the system (included – excluded) – A contract between the systems stakeholders and the systems constructors – Can/will be developed by developers |
| Scenario | A specific sequence of actions and interactions between actors and the system under discussion, e.g. the scenario of successfully purchasing items with cash. – An instance |
| Why identify actors | To find user goals, which drive the use cases |
| Primary actor | – Has goals fulfilled through using services of the System – E.g. the cashier. |
| Supporting actor | – Provides a service to the System. – E.g. The automated payment authorization service. |
| Why identify supporting actors | To clarify external interfaces and protocols. |
| Offstage actor | – An interest in the behavior of the use case, but is not the above. – E.g. Government tax agency. |
| Why identify offstage actors | – Why iden6fy? To ensure that all necessary interests are iden6fied and sa6sfied |
| Use Case Template | 1) Name 2) Scope 3) Level 4) Primary Actor 5) Stakeholder and interests 6) Preconditions 7) Success End Condition 8) Main Success Scenario 9) Extensions 10) Special Requirements |
| The good contract | 1) Complete 2) Consistent 3) Unambiguous 4) Correct |
Created by:
timeakiss
Popular Computers sets