Week 3 Flashcards
(26 cards)
Release cycle for user stories in XP?
- Select user stories for this release
- Break down stories to tasks
- Plan release
- Evaluate system
- Release software
- Develop/integrate/test software
(Repeat- cyclic)
What is refactoring?
XP proposes constant code improvement to make changes easier when they have to be implemented.
Refactoring: improving structure without changing external behaviour.
Bad smells?
Poor or misguided programming.
E.g. code duplication, long methods, large classes, complex conditionals, long parameter list, etc…
Black box vs white box testing?
Black-box testing: tester examines the software without having access to the internal code or implementation details.
White-box testing: tester has access to internal code.
What is a requirement?
High-level abstract statement of a service or a system constrained to a detailed mathematical functional specification.
Requirements engineering?
The process of establishing the service as that a customer requires from a system and the constraints under which it operates and is developed.
User requirements?
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
System requirements?
A structured document setting out detailed descriptions of the system’s functions, services and operational constraints.
Defines what should be implemented so may be part of a contract between client and contractor.
System stakeholders?
Any person or org affected by the system in some way and so who has a legitimate interest.
Stakeholder types?
- End users
- System managers
- System owners
Requirements engineering process?
Requirements elicitation
Requirements analysis
Requirements validation
Requirements management
RE is an iterative activity where these processes are interleaved.
Challenges in RE?
Getting the requirements correct:
- Becomes exponentially expensive to correct mistakes later on. Easier to fix problems in requirement specification.
Requirements completeness and consistency?
Requirements should be both complete and consistent.
Completeness: they should include descriptions of all facilities required.
Consistency: there should be no conflicts or contradictions in the descriptions of the system facilities.
Domain requirements?
Constraints on the system from the domain of operation.
E.g. database, user interface, distributed system.
Functional requirements?
Describes functionality or system services.
Functional user requirements may be high-level statements.
Functional system requirements should describe the system services in detail.
Non-functional requirements?
These define system properties and constraints.
E.g. reliability, response time and storage requirements.
May affect the overall architecture of a system rather than the individual components.
Non-functional classifications
Product requirements
- requirements which specify that the delivered product must behave in a particular way (e.g. speed, reliability).
Organisational requirements
- requirements which are a consequence of organisational policies and procedures (e.g. process standards used, implementation requirements).
External requirements
- requirements which arise from factors which are external to the system and its development process (interoperability, legislation).
Requirements elicitation?
Software engineers work stakeholders to find out:
- About the application domain,
- The services that the system should provide,
- The performance of the system,
- Hardware constrains,
- etc…
- Requirements discovery (gathering)
- Requirements classification and organisation
- Requirements prioritisation and negotiation
- Requirements specification
(Repeats- cyclic)
Problems of requirements elicitation?
Stakeholders don’t know what they really want.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the system requirements.
The requirements change during the analysis process.
Requirements gathering technique: Individual interviews?
Formal or informal interviews with stakeholders are part of most RE processes.
Closed-ended question: based on pre-determined list.
Open-ended question: various issues are explored with stakeholders.
Benefits:
- Privacy
- Possibility to obtain in-depth stakeholder views
Cons:
- Time consuming
- Not good for understanding domain requirements
Requirements gathering technique: Focus groups?
Aka group discussions / interviews
Facilitated by a moderator
Getting people to think about, discuss an issue or set of issues.
Benefits:
- uncover richer set of requirements in shorter periods
- natural peer interactions
Cons:
- dominant speakers
- peer pressure
- success depends on the moderator skills
Requirements gathering techniques: Scenarios?
People usually find it easier to relate to real-life examples.
REs can use information gained from this discussion to formulate the actual system requirements.
Requirements gathering techniques: Ethnographic studies?
Observational study:
- to understand the people behaviours and their cultures.
- requirements that are derived from the way that people actually work rather than the way which process definitions suggest that they ought to work,
Effective for understanding existing processes.
Guidelines for writing requirements?
- Invent a standard format and use it for all requirements and be consistent.
- Use text highlighting to identify key parts.
- Avoid use of jargon.
- Include an explanation of why a requirement is necessary.
