Busy. Please wait.
or

show password
Forgot Password?

Don't have an account?  Sign up 
or

Username is available taken
show password

why


Make sure to remember your password. If you forget it there is no way for StudyStack to send you a reset link. You would need to create a new account.
We do not share your email address with others. It is only used to allow you to reset your password. For details read our Privacy Policy and Terms of Service.


Already a StudyStack user? Log In

Reset Password
Enter the associated with your account, and we'll email you a link to reset your password.

Remove Ads
Don't know
Know
remaining cards
Save
0:01
To flip the current card, click it or press the Spacebar key.  To move the current card to one of the three colored boxes, click on the box.  You may also press the UP ARROW key to move the card to the "Know" box, the DOWN ARROW key to move the card to the "Don't know" box, or the RIGHT ARROW key to move the card to the Remaining box.  You may also click on the card displayed in any of the three boxes to bring that card back to the center.

Pass complete!

"Know" box contains:
Time elapsed:
Retries:
restart all cards




share
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

Requirements based

Contracting, based on requirements elicitation

QuestionAnswer
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