Jonathan Hu

Chapter 17
Part 1 – Summary
Validating requirements is important because it verifies the properties of
requirements are correct. Validation and verification are different things. Validating
requirements ensures that the product and requirements satisfy the customer needs.
However, verification verifies that the development activity from the team is satisfying
the requirements.

Validating requirements allows the development ream to create the proper

solution to meet the objectives. The requirements need to describe the capabilities,
derive from the business requirements, be complete, be necessary, and provide an
adequate basis or baseline to begin development. Validation is not a single phase that
is conducted in the beginning of the project. Validation must be consistently done
throughout the project to ensure that requirements are always on track and in good
standing.

Reviewing requirements is typically done through peer reviews. Peer reviews can
either be forma or informal. Informal reviews are more useful for educating individuals
about the project and collecting initial feedback. Informal peer reviews, however, are not
systematic, and do not have a consistent way of delivering and obtaining information.
Three types of informal reviews are peer deskcheck, passaround, and walkthrough.
Informal reviews can quickly catch obvious issues and gaps, but it is not ideal for
catching more low-level requirements.

Formal peer reviews follow a better-defined process. A formal peer review leads
to having formal requirements that contain a report that identifies the material that is
talked about. Informal reviews, the team shares separate possibilities that ensure the
quality of the review. At the end of the review, the author is responsible for the quality of
the deliverable project.

The most common and best-established formal review is called an inspection.

Inspection of requirements can save countless hours by ensuring that requirements are
 Jonathan Hu

well written and complete. The inspection manages risk analysis and priorities to ensure
that the project is developed in the most efficient way. This can save money in the long
wrong since there is a much lower change of requirements being scrapped and
restarted.

The main inspection roles are author, moderator, reader, and recorder. The
author creates and maintains the work product that is being inspected. The author is
typically the business analyst who elicited the customers needs and created the
requirements. The moderator plans the inspection and coordinates the activities
pertaining the inspection. The moderator works with the author to ensure that issues
from the inspection were addressed properly. The reader inspects the requirements and
points out potential defects. It is good to have multiple readers so that similar issues can
be seen in different perspectives. The recorder records all the issues and defects found
during the inspection. The recorder should be able to capture all the issues and clearly
communicate them to the author.

Part 2 – Personal Experience

At my work we have requirements reviews. In inspector roles are the same. We
have the Author, Moderator, Reader, and Recorder.

In our reviews, the Author also takes the role of the Recorder. The Author
recorders all the defects, comments, and improvements. The Author then takes the
action to approve or disapprove the actions along with the summary of change or
reason for rejection. The Moderator coordinates the meetings and ensures that the
correct stakeholders attend the meetings. The Moderator also ensures that the Author is
properly recording all finds from the reviews. Instead of readers, we call them
inspectors.

The inspectors are stakeholders who have high influence on certain portions of
the project. The inspectors typically consult with the rest of team, but a person is put
down as an inspector, we need that person's concurrence before continuing. Finally, we
also have SQA, which at our company are supposed to ensure process is followed, but
they serve no purpose because they are mismanaged. The moderator usually ends up
doing their job.
 Jonathan Hu

These reviews are very important because they catch flaws that are not initially
obvious. If there are mistakes, they should be found during our reviews and not after
delivery. We have these reviews often and not just at the end of development. We want
to ensure that there are plenty of reviews during development so that errors are caught
before they become too costly to fix
 Jonathan Hu

Chapter 18
Part 1 – Summary
Reusing requirements is beneficial because it helps provide faster delivery, lower
development costs, consistency between applications, better productivity, fewer defects,
and reduced rework. Reusing requirements can also save review time, speed up
approval, and speed up testing. Reusing requirements makes it easier to estimate
implementation because the requirements are familiar from previous development.

Reusing requirements is also beneficial for the customer. Having requirements

that are reused keeps functionality consistent throughout the project. It is frustrating for
the customer if the same function across different platforms has different layouts.
consistency throughout the project makes the customer happy and gives the company a
better reputation for creating reliable projects.

We're using requirements there are models, design comments, code, and tests
that need to be considered. When inspecting these requirements, there needs to be
analysis on which components can be reused. Before reusing requirements, there
should be error handling strategies, internal data logging, communication on protocol
abstractions, and help systems. The functions must be modified appropriately and have
the clear understanding that they are going to be reused.

When we're using requirements, it is very rare that no modification will be

needed. Most of the time, attributes of the function will have to be modified. There may
also need to be modifications to designs and tests depending on how the requirement
will be reused. There also needs to be consideration on how much modification will be
needed. In some cases, if too much modification is needed, that requirement may not
be suitable for reuse.

When creating requirements, it is typically not reusable unless making every

usable was part of the planning phase. If there was no planning for reuse, the
requirement could be too high level or too complex to be modified for other use. There
also needs to be good documentation on how the requirement can interact with a
 Jonathan Hu

variety of systems. Requirements need to be written with the correct amount of

abstraction so that they can be easily modified for future use.

Some bad practices for reusing requirements are missing requirements, writing
style, inconsistent organization, project type, and ownership. All these traits lead to
requirements being difficult to understand and reuse. Some good practices for reusing
requirements are having a repository, quality, interactions, terminology, and
organizational culture. Having good version control, documentation, and structure
allows future developers to be able to understand the code more quickly and implement
it into their own projects.

Part 2 – Personal Experience

Reusing requirements is beneficial because it reduces the cost and time needed
to deliver a functionality. At my work, we basically never reuse requirements between
teams even though we work on the same final project. There is not good communication
between teams, and it is really challenging to create reusable code between teams
without proper management.

My team and another work closely together, but our departments are different.
This means we have different managers and functional groups. We have lots of projects
where code could be reused, but it always ends up being a big hassle to get it working.
Instead of communicating to make a code compatible for both our teams, it seems
easier just to write our own. Since the code was not created from the start with
reusability in mind, it is hard to update it to become compatible for both teams. Without
good management, nobody really wants to put in the effort to better plan out the code to
be reusable.

When requirements are reusable, it saves a significant amount of time at work.

Being able to reuse code reduces review time and development time. Review time is
reduced because their reused code has gone through its own review process and is
trusted. This allows us to focus our review time on newer code. Development time is
also reduced because the code is already written. If the code is easily modified, we do
 Jonathan Hu

not have to spend as much time developing a feature because it was already done for
us.
 Jonathan Hu

Chapter 19
Part 1 – Summary
One of the first tasks during project planning is to estimate requirements effort.
Estimating the requirements effort consists of judging how much of the project’s
schedule an effort is needed towards developing the requirements. The percentage of
time that is spent towards developing requirements depends on the size and complexity
of the project. although time needs to be spent estimating the requirements, it saves
time in the long run because requirements will be developed more efficiently.

when estimating how many resources should be put towards a requirement,

experience is usually the best resource. Looking back at how much time requirements
needed to be completed in the past can help judge how much time it will be needed for
the current project. There should always be consideration on how the requirement will
be changed even if it was done in the past. It is possible that a requirement will be more
complicated than it was in a previous project.

Making realistic estimates on requirements requires that the effort and time be
analyzed. The estimates on the requirements can be based on user stories, analysis
models, prototypes, and user interface designs. Common metrics used to determine the
estimate of a requirement R number of testable requirements, function points, story
points, complexity of elements, and estimated lines of code. All these metrics can be
based off of previous projects.

No matter how good an initial estimate is, there needs to be consideration that
the estimation will change in the future. Customers may change their requirements at
this may cause the analyst to have to update the initial estimation. It is also possible that
during development that something does not go as planned. Any rework or additional
functionality will have to be added into the estimation analysis.

Scheduling is also an important aspect of requirements planning. Effective

project scheduling requires that the estimated product size, productivity, list of tasks,
requirements, an experience are all evaluated. Scheduling is important because it not
 Jonathan Hu

only determines how long the project will take, it also provides an analysis of how much
the project will cost. The customer wants to know the project schedule because it will
give them a good idea of how much time, resources, and money it will take to complete
the project or requirement.

Part 2 – Experience
My team at work has had problems with estimating requirements efforts in the
past. Whenever it was time for a new, project, the estimation period would either be way
too short or way too long.

When the estimation period was too short, it felt like we never actually left the
estimation phase of the project. Throughout the project, we constantly found too many
things that were vague or missing and we had to have unplanned meetings constantly.
The meetings would address the found issues and fix them as we went along. This was
an inefficient use of time and it felt like many of the issues could have been accounted
for if the project was better planned from the start.

On the other hand, we would sometimes be stuck in the estimation period for way too
long. When this happens, we sometimes wonder when the project is going to start. We
get assigned to do a lot of "preparation work" that doesn't seem to matter all that much.
Very little of that work ends up going to the project so it feels like wasted resources.
While it is great that they want to address every little detail, there needs to be a risk
tolerance so that we can leave the estimation period and actually start of the project.

In the beginning, requirements estimation may seem like it is taking a lot of time
and developers may get frustrated because the estimation is causing development to
delay. However, good requirements estimation can save a lot of time in the long run.
Good estimation provides a good schedule that allows the requirements to be
developed more efficiently and effectively. It also provides a better allocation of
resources for the developers.

Requirements estimation requires a lot of communication with the customer. The

person on our team that oversees requirements estimation is constantly on meetings
with the customer. Customer constantly is changing their line and we have to update
 Jonathan Hu

our estimation plans. Have the estimation planning is an ongoing process that ever
really end till we're close to finishing development.
 Jonathan Hu

Chapter 27
Part 1 – Summary
When developing requirements, the activities are to elicit, analyze, specify, and
validate the project requirements. These requirements can include business
requirements, user requirements, functional requirements, nonfunctional requirements,
data dictionaries, and analysis models As requirements are reviewed and approved,
they become part of the baseline. The baseline is the set of agreed on requirements
that are part of the project.

The baseline is not a set-in stone requirements list. As the scope of the project
changes, the requirements baseline is also changed accordingly. Projects can
accommodate new changes and update the baseline in various ways. Changes can be
accommodated by differing lower priority requirements into later iterations, obtaining
additional staff, extending the delivery schedule, or sacrificing quality. There is no one
correct way to manage changes, but there are sometimes compromises needed to
manage budget, schedule, quality, and flexibility.

Version control is important when updating the baseline and requirements.

Version control is used to uniquely identify different versions of requirements. Every
version of the requirement must be accessible so that the team can see how
requirements have evolved. This minimizes confusion and miscommunication when
discussing requirements. A good tool should be able to include a revision history that
identifies the exact change, date of the change, individual who made the change, and
reason for the change.

Attributes are needed when defining requirements. Each requirement needs

properties that distinguish it from other requirements. There is more than just text that
describes the requirement. There needs to be attributes too. Some examples of
attributes are date, version, author comic priority, status, origin, and rationale, release
version, stake holder contact information, and validation method.
 Jonathan Hu

As requirements are made, there needs to be a way to track the requirements

status. As requirements are developed, there should be a way to determine how much
of the project is completed. Tracking the status of requirements also gives management
a way to communicate to the customer about how progress is going with development.

Part 2 – Personal Experience

Requirements managing is very important as it keeps track of how requirements
evolve and change. At work, we use Jira to manage our requirements. Jira is used to
version control, change control, track, and trace requirements. Version controlling is
important because it helps us understand how requirements evolve. We want to know
why requirements change and the backstory that comes with the requirement updates.
This helps us track mistakes or misunderstandings from pervious requirements.

We also want to record all the change controls. This includes all the notes that
were recorded when discussing the requirements. We never know when we might
reference need to reference them again even if the ideas were rejected. Managing the
requirements also helps us link requirements together. It is very beneficial to be able to
see the relationships between different requirements. It helps us prioritize requirements
and assign requirements to be completed more efficiently.

Even though we have good software and process to track our requirements and
processes, it is only as good as the team makes it. If developers are not updating their
tickets and statuses as development progresses, it is the equivalent as if the progress
was not tracked at all. Our team lead spends a lot of time tracking all the team members
and making sure that they update their statuses. It also looks bad when we do not
update our Jira tickets because seems like the project is not making any progress.

We also make sure that we have a robust system of tracking our requirements.
We have a redundant system which makes it so that we have two places where we
store requirements. It is essential that we do not lose our requirements tracking or we
no longer have data for communicating to the customer. We have two servers for Jira to
ensure that we always have a backup incase servers go down or something goes
wrong.
Jonathan Hu
 Jonathan Hu

Chapter 28
Part 1 – Summary
Changes in software are necessary. It is not possible to accurately define all the
product requirements before development. software changes because opportunities
arise, regulations change, and businesses evolve. it is important that a team can't
respond to necessary changes as they come. The changes must be also made in a
timely manner to satisfy the customer. When managing software products the proposed
changes are thoughtfully evaluated, individuals are informed, activity is made visible to
stakeholders, approved changes are communicated, and the requirement changes are
incorporated in an effective and consistent matter.

While change is important, it comes at a price. Some changes are very simple
and quick where other changes can be much more complicated and cost a lot of money
and resources. Even if a change is rejected call mom it still costs resources and time to
submit, evaluate, and decide to reject it.

Issues with changes also occur when they are implemented without proper
communication. Documentation becomes unorganized and other team members’ work
are affected. if a change on one requirement is not properly communicated with the rest
of the team, the other requirements are not updated so that they are still compatible with
the new requirement. This can lead to frustration, re work and wasted time.

When there are a lot of changes or new requirements, scope creep becomes an
issue when developing a project. Ideally, all requirements are defined at the beginning
of the project, but this doesn't work in practice. As requirements grow and change,
scope creep becomes an issue that causes a lot of projects to fail. Eventually the
requirements become overwhelming, and a project goes over budget.

To manage scope creep, the team must document business objectives, product
vision, product scope, and limitations of the system. Proposed requirements must be
accepted or rejected rather than just throwing all of them into the backlog. Prototyping
also helps control scope creep because it gives a better understanding of user needs
 Jonathan Hu

and perspective solutions without using as many resources as possible. Shorter

development cycles to release features also helps provide opportunities to fix issues
and make adjustments.

Part 2 – Personal Experience

When changing requirements, I found at work that it is easy to become narrow
sighted and rabbit hole into that change. When something does not go right, we have an
instinct fix that the direct source of the problem. While this usually fixes the issues, there
are management and logistical issues that need to also be considered.

The first thing we need to consider is the impact that the new change will have on
other requirements. If fixing one requirement also results in major rework on other
requirements, risk management needs to be considered. The time it takes to change
and incorporate a requirement needs to also be considered. Changing a requirement
can sometimes result in an overhaul of the code and take a lot of time to fix. This has
led us to go over budget and miss deadlines in the past. While it is important to fix
requirements based on customer needs or findings, it needs to also be properly
communicated that it is not always feasible or that the cost may increase a lot.

Our team has also had issues with scope creep. Since I am the only developer
for majority of our projects, I sometimes get overwhelmed with the number of
requirements that are requested. When I start a project, I am usually given a list of
requirements that are needed. Usually, the requirements are clear, and I have a clear
definition of what I am going to deliver.

Issues occur when requirements are requested during development. As the

requirements are piled on to the project, I eventually end up with too many requirements
to implement. This leads to an issue where the project will never be finished if
requirements are constantly added onto the backlog. We end up having to prioritize the
requirements in the backlog and choose which features we think are most important.
This endeavor to believe ends up with some people upset because their requested
feature did not make it into the final built. However, if we do not prioritize and choose
requirements, the project will go over cost and fail to deliver.
Jonathan Hu