Transcript Requirements - School of Computing and Engineering

Requirements
"The hardest single part of building a software system
is deciding precisely what to build." [Brooks, 1987]
Before you can build something you have to
know what it is that needs building.
Requirements is an area of software
engineering concerned with the elicitation,
analysis, specification, and validation of
software requirements.
Definition
Requirements—internal and external capabilities
and characteristics of the system necessary to satisfy
the explicit and implicit needs of the customer and/or
user.
Sometimes it helps to make a distinction between
product and project requirements. For example, a
product requirement might be that a certain report is
produced. A project requirement might be the total
system changes be completed in 6 months.
Requirements drive several
down-stream activities
Levels of Requirements
Three Distinct Activities
Types of Requirements
Distinguishing between functional and
non-functional requirements
• It’s useful to make a general distinction between
functional (FR) and non-functional requirements
(NFR) because they are managed differently.
– FRs (and constraints) are discrete; NFRs are present to
a degree. You can have more or less of a NFR
depending on other project priorities. FRs are either
present or absent.
– One NFR may conflict with another. Therefore they are
more often prioritized than specified with precision.
Example Non-Functional
Requirements
• Non-Functional Requirements important to users:
– Usability, availability, efficiency, integrity,
robustness, flexibility, interoperability, reliability
• Non-Functional Requirements important to
developers (and indirectly important to users):
– Maintainability, reusability, testability, portability
Expressing Functional Requirements
• Functional requirements are typically
expressed using a combination of:
– Use Cases (scenarios of use)
– System shall’s
Expressing Non-Functional
Requirements
• Non-functional requirements should be
specified in a measurable way. They should
be testable.
• Non-functional requirements may be
specified with system shall’s.
• Is the following a non-functional
requirement? Is it well-specified?
The system shall be easy to use.
Requirement Engineering
Requirements Development
• Understand the problem or opportunity
• Determine the system behavior that will
address the identified problem or opportunity
• Document the desired system behavior in a
written specification
Baselined Software Requirements
Requirements Change Management
• Manage changes to baselined software
requirements.
Requirements tend to evolve and
become more certain with time
Known requirements at the start of iteration #1
Participants in the Requirements Process
• Customer—the person who is paying for the software.
Even though the customer might not be a user of the
system, the customer has significant influence over the
requirements.
• User—the person that will interact with the application.
• Product manager/champion—the person that represents the
voice of the customer. This role is especially useful when
the customer isn’t easily identified or available.
• Developer—the person designing and implementing a
solution.
• Analyst (aka Requirements Engineer)—the person
responsible for eliciting the requirements. The liaison
between the user/customer and technical staff.
Requirements Development Process
Elicitation
•
•
•
•
Study existing written material
Observe environment
Interview users and customer
Help users and customers understand
technical possibilities
• Convey relative costs of different
implementation options (this will help the
customer decide requirements and priorities
among requirements)
Interviews
• Don’t confuse goals with mechanisms to
achieve goals.
• Is “log in” a mechanism, a goal, or
something else? (e.g. “First the user logs
in”)
• The best way to find out is to keep asking
“why”.
Usage Scenarios
• Walking the client through detailed scenarios of use is one
of the best ways to ensure you understand the requirements
as well as you think you do.
• Your brain has a wonderful capacity to fill in missing
details. Most of the time this capability serves you well.
Not so much during a requirements meeting.
• If you don’t resolve them during the requirements meeting
you will have to ask later, or worse, make assumptions.
• It’s more efficient to resolve them during the requirements
meeting.
Analysis
• Elicitation is about gathering requirements,
analysis is about organizing and understanding
them better.
• During analysis priorities are established, detail is
added and missing requirements or unknowns are
identified.
• Analysis models may be used to better understand
the problem domain and system under
development
– Types of models that might be helpful during
requirements analysis include: screen flow diagrams,
data flow diagrams, use case models, activity diagrams,
and state machine diagrams.
Apparently not all
“requirements” are required
• A 2002 study from the Standish Group found that
65% of the features/functions implemented in a
typical software system are never or rarely used. I
guess they weren’t “required”.
Specification
• Requirements are documented in a Software
Requirements Specification (SRS)
• Uses cases are the most common way of
exploring/analyzing and expressing
functional requirements
• Be sure to rank or prioritize requirements
according to business value, cost, risk,
stability (likelihood of changing).
Validation
• Use prototypes and other means to verify
with users and customer that your
understanding of the requirements is
complete and correct
Characteristics of a good SRS
•
•
•
•
•
•
•
Correct–above all else the requirements must accurately reflect the actual needs, wants and
expectations of the user/customer.
Unambiguous–requirements open to multiple interpretations can create problems later during design,
implementation and acceptance testing.
Complete–the requirements document is complete when all functional and non-functional
requirements as well as constraints on design and implementation have been addressed.
Consistent—requirements are consistent if there are no contradictions
Prioritized—there is rarely enough time or money to implement all of the features the customer
desires. Therefore it is important to prioritize the requirements to ensure that the customer receives
maximum value for time and money invested.
Verifiable—every requirement should be stated in such a way that it is possible to definitively and
cost-effectively test for the presence of the requirement. For example, the following requirement is
not verifiable: “The system shall be easy to use.” It does convey the fact that usability is a high
priority non-functional requirements, but “easy” is too subjective. A more quantitative way to state
the objective is, “Ninety percent of the users that fit the average user profile specified in section x.y
can complete all essential features without consulting the user manual.” Ambiguous requirements are
naturally unverifiable.
Traceable—traceability is easy in concept but hard in practice. A requirement has backward
traceability if you can work backward and uncover the source or reason for the requirement. A
requirement has forward traceability if there is a link from the requirement to all design,
implementation and test cases that pertain to the requirement. The requirements document doesn’t
have to contain the actual links to other documents to be traceable. For example, it may be that each
requirement in the requirements document has a unique ID with a traceability matrix specified in a
separate document.
SRS Outline
• Introduction: project vision, scope, purpose, goals, objectives (Possibly
specified somewhere else but referenced in SRS.)
• Definitions, Acronyms, Abbreviations
• Features
• User Classes, User Characteristics
• Assumptions and dependencies (“We assume there will be a user
representative available with authority to answer our requirements
questions in a timely manner”)
• Constraints
• Requirements (system shall’s)
– Functional Requirements
– Non-Functional Requirements
•
•
•
•
Window Navigation Diagram (where applicable)
Use Cases
User Interface Design
System boundaries and system evolution
Software requirements
in three easy steps
• What are the classes of users? (Administrator,
Supervisor, Office Assistant, etc.)
• What are the goals associated with each class of
user? (Enter profile information, Edit patient data,
query patient identification data, etc.)
• What system behavior is needed to accomplish
each of the goals for each of the user classes?
Visual Blind Spot
• Your brain is wired to fill in missing details from sensory
inputs. For example, many people consider the human eye
like a camera, taking in high resolution snapshots of the
world.
• The feeling is, you might not be able to remember
everything you see, but you can trust your eyes are
delivering a full picture of the world around you to your
brain.
• The truth is your eye is not a camera.
For one, you have a blind spot in your
visual field. It’s due to the lack of
light-detecting photoreceptor cells at
the point where the optic nerve
passed through the retina.
Blind Spot Test
• Position your face close to the screen. Close your
left eye and stare at the dot with your right eye.
Now slowly move away from the screen while
staring at the dot with your right eye. At about 15
inches away, the cross will disappear. Note, you
don’t see a hole. Your brain fills in what it
expects to see based on the surrounding area.