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?
-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
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+?
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