PROG8060

Developing Quality Applications

Winter 2024
From the Course Outline:
 2.0 Software Requirements Analysis
 2.3 Identify the key methods and techniques used in eliciting for requirements and
specifications.
 2.5 Validate requirements by employing techniques such as requirements reviews,
prototyping and incorporating acceptance testing.
 2.6 Adapt system requirements to the iterative nature of software development by
employing change management techniques and procedures.
 2.7 Identify the differences between uncertainty and risk for a software development
project. Utilize risk assessment and mitigation techniques to manage perceived risk.

 Project Work
 Once we have identified the sources for our Requirements, we
would then need to elicit information from them to provide
input into the Design and Development stages that follow

 The key thing when eliciting information from the sources is

to elicit the right information and the right amount of
information.
Interviewing

 Have the benefit of learning from others and their knowledge

 Mostly focused on interacting with Subject Matter Experts (SME’s) and
their knowledge base
 Allow for the collection of large amounts of data quickly
 Dependent upon the skill of the interviewer and their ability to ask the
right questions
 Best practice is to utilize open-ended questions
Brainstorming

 Can avoid potential pitfalls later on in the project by enlisting the help
of others on the team to provide input
 Allows others to provide input in a non-judgemental forum
 Allow for the collection of information from a wide variety of
perspectives
 Allows for creativity and thinking outside of the box
 Best practice is to utilize mind mapping software for greater
collaboration
Observations

 Find out where the product is currently and customers perspectives

 Allows us to see what is currently working or not working with a
product already in existence
 Allow for the collection of workflows that can be diagrammed at a later
time
 Subjects may change the way they are performing tasks if they know
they are being observed
 Best practice is to set the tone, scope and outcomes with your users
Workshops

 Basic requirements can be done / captured expeditiously

 Can be highly productive if everyone is engaged
 Allow for the participants to be engaged at the onset of the project
 Can get a variety of perspectives
 Best practice is to conduct the workshop like an interview and to
document everything
Prototyping

 Have the benefit of providing a sampling of your application and getting

quick feedback on the direction
 Mostly focused on making it easier to allow users to provide feedback on
their own time, convenience
 Allow for SME’s and other stakeholders to play an active role in defining the
requirements
 Cannot do this too early in the cycle
 Best practice is to provide a prototype with some of the key, high priority
features that are important for the customers.
 So, now that we have a set of Requirements for our application /
program, and we have elicited these requirements using a
variety of techniques, how do we know that we’ve documented
for building the correct product? Or a product that the
customer will actually use?

 This is where we’ll need to validate the requirements using

another set of techniques beyond “going back to the customer”
 So, now that we have a set of Requirements for our application /
program, and we have elicited these requirements using a
variety of techniques, how do we know that we’ve documented
for building the correct product? Or a product that the
customer will actually use?

 This is where we’ll need to validate the requirements using

another set of techniques beyond “going back to the customer”
 Normally, a Business Analyst (BA) will produce a use case to
document the way in which the software will be used – however,
there still may be a certain uncertainty if the use case is indeed
correct.
 From anecdotal information, about ~ 35% of use cases will change
after they have been through some validation – as such, there is
certainly worth the effort to validate requirements.
 If this validation is not done at this stage, this will lead to more re-
work by the development / testing teams – thus causing potential
delays
 Reviewing the requirements by a cross-functional group of
individuals within the project team (such as developers, testers,
business analysts, product designers, product management) will
ensure from these perspectives that the requirements can be
validated.
 Having the development team create prototypes of the overall
solution will allow for faster and more precise feedback from the
customer / client as to whether or not will be sufficient.
 Acceptance Testing is testing performed (mostly) by the
customer in their environment to ensure that the solution will
work for them.

 Customers can provide feedback as to one of the following

outcomes:
 Accept the solution as is without any changes
 Accept the solution only after changes have been made
 Do not accept the solution
 Iteration Planning sessions allow the project team to provide
estimates for each use case and how many use cases / user
stories can be accommodated for the upcoming iteration to
meet the Definition of Done

 The main focus for companies using Agile is to be able to

accommodate changes to the requirements much more easily –
this is where each Iteration Planning sessions can provide
updates and more clarification to any upcoming requirements
and to constantly see if we’re building the right product.
 Requirements typically follow an iterative process to provide a
certain level of quality and detail to allow design decisions to be
made.

 Requirements can be baselined to only those that are required for

the current iteration.

 This process allows the designer / product manager to continue to

refine the requirements for upcoming iterations while the
development team continues to work on the current iteration.
 The whole premise around using Agile for software development
is around anticipating for, dealing with and monitoring change
(mostly around requirements / objectives)

 “Change is Constant”

 When using Agile, we want to put the focus on developing high-

quality and high-value software that our customers will want to
use.
 Key thing: prioritize your requirements and implement the highest
priority items sooner rather than later.
 Each iteration should strive to implement the highest priority
items sooner rather than later;
 Higher priority items should have the most detail defined for
them;
 Lower priority items are those work items that may not have
too much details associated with them yet;
 New work items can be prioritized and then added to the
overall backlog of work items;
 Work items no longer applicable in the current
implementation can be removed or moved lower in the list
 Work items removed / reprioritized
Increasing detail and priority

Work items added / reprioritized

Decreasing detail and priority

 Within Scrum, requirements should be “frozen” for the current
iteration or sprint – that way, the development / test teams
working on this iteration have some sense of stability

 Changing a requirement that is currently being worked on in the

current iteration would be treated as a brand-new requirement
for an upcoming iteration.
 Features were missed during early planning

 Significant defects were found earlier

 Change in the marketplace / needs of the customer

 Customers didn’t realize their actual need

 Change in regulatory / legislative aspects

 When we’re talking about uncertainty or risk, these two terms may
often be associated with one another – but are in fact very different
when managing projects

 With Risk, we can to some degree predict the possibility of an

outcome in the near future. As a result, risk can be managed and
monitored after it has been identified

 With Uncertainty, we have no way of predicting the possibility of an

outcome. As a result, uncertainty cannot be managed or monitored
 Suppose we are asked about what team will win a Basketball game.
Both teams have really good, star players.

 Without further information, we won’t be able to tell which team

will win. This is uncertainty.

 However, if we’re told that all of the star players will be playing for
Team A and the star players for Team B won’t be, we can say with
some level of confidence, that Team A would have better chances of
winning – this is analyzing the risk involved in this situation.
 Now, suppose we are dealing with a software development project and we
need to identify if it will succeed or not.
 Based on this lack of information, we have a lot of uncertainty – especially if
this a project that our company has never handled in the past.
 However, if this project is a derivative of another, similar project that we did
previously, we can say with some level of confidence whether that project
will succeed or not. This would be based on whether:
 the requirements were similar,
 the same resources will be used in this new project and
 whether we have a similar amount of time.
 Like with any activity, there exists risks in software engineering as
well…for instance:
 Cost overruns
 Undelivered / untested features
 Loss of resources (including human, technical resources)
 Delays
 Assumptions and Dependencies – which can possibly affect delivery, scope,
time
 Constraints and Limitations – affecting scope, time
 Project failures
 Brand tarnishing / social impact
 As software developers, testers we have responsibilities to identify
project risks from our perspectives, analyze them, prioritize them
and find ways to eliminate or mitigate the risks.

 We will be using project risk management techniques to:

 Help identify the risks associated with software development / testing;
 Prioritize the identified risks and;
 Decrease the probability and impact of negative events from occurring
during our phase within the overall Software Development Life Cycle (SDLC).
 External: Regulations / legislation, markets, customers, vendors

 Internal: Resources, budgets, time, prioritization

Scope

Quality

Resources Time
Identify Risks Perform Risk Risk Response Monitor and
Analysis Control Risks

• Determine the • Qualitative • Mitigation • Measurements

sources of risk • Quantitative • Elimination • Criteria setting
• Transferring • Responses
• Acceptance
 One of the key steps in managing any risk – reviewing
documentation, mind mapping, checklist analysis,
assumption analysis, SME consultations, past projects.

 As we seen earlier, from the sources of the risk, we need to

identify which risks have the highest probability of occurring –
e.g. more likely that builds will be delayed than a meteor
striking our facility
 The process of identifying risks is usually iterative because
identifying risks occurs over the entire SDLC

 Some common risks that can be identified within testing:

 Requirements not complete or incorrect
 Not receiving software to test in a timely fashion
 Too many critical issues found during testing
 Scope creep – increasing the amount of testing required
 Slow turnaround in fixing high priority issues
 Needs to be performed from both a qualitative (subjective)
and a quantitative views.

 Take into account: Scope, Time and Resources

 Qualitative: classification of risks and their impacts: high,

medium or low

 Quantitative: quantifying the probability and the

consequences of each risk
 During Sprint planning, we should look asking team members to
brainstorm about what could be some sources of risks the could be
upcoming

 From this list, we can then continue to pursue what would happen if any
of these risk items were to materialize

 For instance, we can have a risk that “customers unable to place their
orders online”, for which, we can ask “Why?” - “the website will not be
functional” and then continue to ask “Why?” – to which, we can think of
“we don’t have all of the components developed for it”. Then from here,
we can develop a plan to address this risk.
 Risks to our project – the rocks

Our Project – the ship

 When risks have been identified and analyzed, the following
actions need to be documented if and when the risks actually
manifest themselves:
 For accepting any risk, you have decided to take no action and
to just accept the outcomes of that risk if and when it occurs

 Good strategy for small risks – those that will not have much
of an impact on your project and can be easily dealt with

 For example: employee illness

 To avoid the perceived risk, you would have to change your
plans completely.

 Good strategy for when the risk has a potentially large impact

 For example: testers taking time off from work for some non-
technical training. During this time, they will not be working
on a critical project. As such, we can see if this training can be
rescheduled for a later time.
 Transference or transferring the risk to someone else.

 Not used very often (why would anyone else want to take on
YOUR risk?)

 Example: Third party software development firm would have

to fix their own issues and ensure their deliverables are of a
certain quality before it can be used.
 Most commonly used technique in Risk Response as well as the
easiest to understand and implement.
 Essentially what you’re doing is limiting the impact of a risk. This
way, if the risk occurs, the problem it creates is smaller and easier
to manage.
 Example: For testing large or riskier changes to software, rather
than testing it after development has finished, maybe there are
opportunities to test alongside development (and possibly on
their feature branch) and then commit after running the tests.
 Let’s split up into our groups and consider the following situation:

 We are all going on a (fictitious) trip! Some things are known but
others are not. Each group will be going to a different destination.
You and your group will be planning on what you’re going to take
along for this trip in terms of the following:
 Costs
 Consequences
 Context
 Choices
Group # Destination Spending Money Duration
(all departing from Kitchener - Waterloo) (per person)
1 Tokyo $2000 4 days
2 Moscow $2000 10 days
3 Ottawa $200 3 hours
4 Cairo $2000 7 days
5 Antarctica $8000 4 months
6 Cambridge $20 ½ hour
7 Vancouver $200 1 day
8 Beijing $500 5 days
9 Auckland $1000 7 days
Plan your trip with your group members with regards to what you will take along with you based on the
above mentioned information. Post your thoughts using the white board. Make sure to base these notes
on the risks involved using costs, consequences, context, and choices.
 Any questions?