Question | Answer |
Large System Characteristics | Many developers
! Geographical distances
! Different time zones
! Different cultures
! Different languages
! Different technical skills
! Organizational challenges
! Sharing source texts
! Frequent deliveries Case:
! several subsystems: |
Object Constraint Language | is a declarative language for describing rules that apply to Unified Modeling Language (UML) models developed at IBM and now part of the UML standard. |
Agile highest priority | Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software. |
Agile emphasizes | Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan |
BPR | Business process reengineering (BPR) is the analysis and redesign of workflows within and between enterprises in order to optimize end-to-end processes and automate non-value-added tasks. |
Requirements Elicitation vs. Analysis | Requirement elicitation creates documents understandable for users/clients
◦ Natural language
Analysis creates documents understandable for developers ◦ Formalized language |
Requirement elicitation qualities | Realistic
◦ Can it be implemented
! Verifiable
◦ Can we test that the requirements have been
fulfilled
! Traceable – both ways
◦ From requirement to implementation ◦ From implementation to requirement |
Activities of Requirements Elicitation | Identify actors
! Identify scenarios (as-is and to-be)
! Identify Use Cases
! Refine Use Cases
! Identify Initial Analysis Objects
! Identify Non-functional requirements |
JAD (Joint Application Design) | ! Goal: Mutually accepted solution
! Participants: User, Client, Developer ! JAD facilitator |
Tracebility | ! Where does the requirement come from? ◦ Backward traceability
! Where is the requirement implemented in the system?
◦ Forward traceability
◦ If I change this requirement then what else should be changed |
RAD | The Requirement Analysis Document
1) Introduction
2) Current System
3) Proposed System
4) Glossary |
Software Lifecycle Activities | 1) Requirements Elicitation
2) Analysis
3) System Design
4) Object Design
5) Implementation
6) Test |
Techniques to Requirements Elicitation | 1) Questionnaires
2) Task Analysis
3) Scenarios
4) Use Cases |
Scenario Based Design | ! Focuses on concrete descriptions and particular instances, not abstract generic ideas
! It is work driven not technology driven
! It is open-ended, it does not try to be
complete
! It is informal |
Types of Scenarios | 1) As-is scenario
2) Visionary scenario
3) Evaluation scenario
4) Training scenario |
Heuristics for finding scenarios | ◦ primary tasks that the system needs to perform?
◦ What will the actor create, store, change, remove or add in the system?
◦ What external changes does the system need to know about?
◦ What changes actor of the system need to be informed about? |
Types of Requirements | 1) Functional
2) Non-functional
3) Constrains |
Non-Functional Requirements | Usability
Reliability Robustness
Safety
Performance Response time
Scalability Throughput Availability
Supportability Adaptability
Maintainability |
Requirements Validation | 1) Correctness
2) Completeness
3) Consistency
4) Clarity
5) Realism
6) Traceability |
Tools for Requirements Management | 1) DOORS
2) RequisitePro
3) RD-Link
4) Unicase |
Different Types of Requirements Elicitation | 1) Greenfield Engineering
2) Re-engineering
3) Interface Engineering |