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):

What are requirements?

A complete description of what the system needs to do


Who has an interest in the requirements?

-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


How important are requirements?

-Can cost more later on if requirements are wrong.
- Majority of projects that fail are because of requirements either being wrong or changing


How do we elicit requirements?

-Quiz users
-Shadow users
-Quiz management
-Look at current systems


What problems can occur when eliciting requirements?

-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


How can requirements change?

-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


How do we get a requirement?

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


What language are requirements in?

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


What areas do requirements cover?

-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


What are functional requirements?

These are tasks the system must perform


What are Non-functional requirements?

Constraints placed upon the system or us


What is FURPS+?

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


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

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


What is a problem with requirements?

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


What makes a good requirement?

-Can be verified
-Supports decision making, planning and prioritising


What is the main parts of a requirement?

-Explanation of why necessary
-Other attributes


What are some ways of organising requirements?

-By features/behaviours
-User groups
-Mode of program