Lecture 5 - Managing Requriements Flashcards

(17 cards)

1
Q

What is PEGS?

A

A way to define requirements, the aim is to execute:
- a Project
- in a certain Environment
- to achieve a certain Goals
- by developing a System
===
Where each has its own components such as:
Project Book: tasks and schedule
Environment Book: stakeholders, goals
Goals Book: compontents and constraints
System Book: functionality and interfaces

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is the difference between projects and goals?

A
  • Project Requirements concern how the SW development will be carried out where as, Goals Requirements capture the business goals of the system why we are building it
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is the difference between the system and the environment?

A

The system is the objects within the environment whereas the environment is any outside factor that can affect the requirement

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What are the sources of requirements?

A

“Requirements document”
Meeting minutes
PowerPoint presentations
Emails
Regulatory documents
Code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are the attributes for a good requirement specification?

A
  • Concise
  • Complete
  • Testable
  • Feasible
  • Modifiable
  • Traceable
  • Easy to change
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What are the three parts of the requirement analysis framework?

A
  • Functional model: use cases & scenarios
  • Static analysis object model: class & object diagrams
  • Dynamic model: sequence diagrams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is the goal of the requirement analysis framework?

A

Goal is to investigate the problem domain as far as possible before moving to the solution domain (i.e., design & implementation)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is a UML class diagram?

A
  • A class diagram describes the types of objects in the system and the various kind of static relationships that exist among them.
  • Class diagram also show the properties and operations of a class and the constraints that apply to the way objects are connected.
    REFER TO SLIDES FOR EXAMPLES
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What is multiplicity - in reference to UML class diagram?

A

The multiplicity of a property is an indication of how many objects may fill the property

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What are the 3 conditions of multiplicity?

A

1 can only have exactly 1
0..1 means between 0 to 1 (can also have 1 .. 5 or 0 .. *)
* no upper limit on how many there are

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is Class Responsible Collaboration (CRC)?

A

Technique uses to analysis and organise classes within a system
NOTE: typically defines the role of the class and its collaborator (the other classes it links to if required)
REFER TO SLIDES FOR EXAMPLES

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What is the difference between Analysis and Validation?

A
  • Analysis works with raw requirements as elicited from the system stakeholders
  • Validation works with a final draft of the requirements document i.e. with negotiated and agreed requirements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What are the validation outputs?

A
  • Problem list
    – List of discovered problems in the requirements document
  • Agreed actions
    – List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions
  • Management tools for this
    – Requirements document with version tracking
    – Issue tracking support
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What are Requirement Reviews?

A

A group of people read and analyse the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

What are the criteria of the review checklist?

A
  • Understandability
    – Can readers of the document understand what the requirements mean?
  • Redundancy
    – Is information unnecessarily repeated in the requirements document?
  • Consistency
    – Do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements?
  • Organisation
    – Is the document structured in a sensible way? Are the descriptions of requirements organised so that related requirements are grouped?
  • Conformance to standards
    – Does the requirements document and individual requirements conform to defined standards? Are departures from the standards, justified?
  • Traceability
    – Are requirements unambiguously identified, include links to related requirements and to the reasons why these requirements have been included?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What are the checklist questions that can be asked?

A
  • Is each requirement uniquely identified?
  • Are specialised terms defined in the glossary
  • Do individual requirements use the terms consistently
  • Are related requirements grouped together? If not, do they refer to each other?
17
Q

What are the 10 test for requirements?

A
  1. Does each requirement have a fit criterion that can be used to test whether a solution meets the requirement?
  2. Is every requirement in the specification relevant to this system?
  3. Does the specification contain a definition of the meaning of essential terms within the specification?
  4. Is every reference to a defined term consistent with its definition?
  5. Is the context of the requirements study wide enough to cover everything we
    need to understand?
  6. Does the requirement contain a rationale?
  7. Have we asked the stakeholders about conscious, unconscious and undreamed of requirements?
  8. Does the specification contain solutions posturing as requirements?
  9. Is the stakeholder value defined for each requirement?
  10. Is each requirement uniquely identifiable?