OO Requirements (PPT 3-4) Flashcards Preview

Object Oriented Analysis and Design > OO Requirements (PPT 3-4) > Flashcards

Flashcards in OO Requirements (PPT 3-4) Deck (17)
Loading flashcards...
1
Q

What are requirements?

A

A complete description of what the system needs to do

2
Q

Who has an interest in the requirements?

A

-Analyst: What problem needs to be solved
Designer: What solution will address these
Software Dev: What am I building
Tester: Does the system meet the requirements
Project Manager: Prioritising, decision making
Sponsor: What am I getting for my money
User: What will my day to day involve

3
Q

How important are requirements?

A
  • Can cost more later on if requirements are wrong.

- Majority of projects that fail are because of requirements either being wrong or changing

4
Q

How do we elicit requirements?

A
  • Quiz users
  • Shadow users
  • Quiz management
  • Look at current systems
5
Q

What problems can occur when eliciting requirements?

A
  • Varied stakeholders: Everyone has different agendas and different needs
  • The shopping cart problem: Management can say yes to everything. Have to choose between Good, fast or cheap
  • Difficulty expressing: conscious needs, unconscious needs, undreamed of needs
6
Q

How can requirements change?

A
  • The environment can change, such as laws standards or tech
  • They weren’t understood properly in the first place, such as misinterpreted or not clearly expressed
  • Requirements creep: new features creeping in unnoticed
  • Victims of your own success: Can move from anything will do to what if we don’t get everything
7
Q

How do we get a requirement?

A

We take user’s needs and turn them into features. From there, we turn it into a requirement

8
Q

What language are requirements in?

A

They use a formal language with the words Shall, Should and May

9
Q

What areas do requirements cover?

A
  • Information to be held or used by the system
  • Format of that information
  • Calculations or procedures to be performed
  • Outputs/results from these procedures
  • Data validation
10
Q

What are functional requirements?

A

These are tasks the system must perform

11
Q

What are Non-functional requirements?

A

Constraints placed upon the system or us

12
Q

What is FURPS+?

A

F: functionality
U: usability, e.g. user firendliness
R: reliability, e.g. accuracy of calculations, % downtime
P: performance, e.g. response times, throughput
S: supportability, e.g. maintainability, compatibility, scalability
+: Other requirements, e.g. documentation standards, design constraints

13
Q

What tends to be the split of functional vs non-functional?

A

80 or 90% however this can depend on the system.

14
Q

What is a problem with requirements?

A

The language which is used can be vague if there is no standardisation

15
Q

What makes a good requirement?

A
  • Unambiguous
  • Realistic
  • Can be verified
  • Supports decision making, planning and prioritising
16
Q

What is the main parts of a requirement?

A
  • Identifier
  • Description
  • Explanation of why necessary
  • Other attributes
17
Q

What are some ways of organising requirements?

A
  • By features/behaviours
  • User groups
  • Mode of program