OO Requirements (PPT 3-4) Flashcards
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?
- Unambiguous
- Realistic
- Can be verified
- Supports decision making, planning and prioritising
