Methods I would use to gather requirements for writing a sales software where the
two partners could not agree on what exactly the software should do:
1. I would do research on the current system and business. m The first thing I
would do is understand the business mission statement to understand the
business goal and what is important to the business. Next, I would research
to see what sales software they are using. In doing this I would look to
understand the pros and cons of the current system and why an upgrade is
needed.
2. I would conduct an interview with both partners together. I would start the
interview off with verifying the business mission statement to help align the
two partners in what they want the new software to be. I would then review
the current system with them and understand what they like, don’t like and
why they want a new program. I would ask each partner to take turns on
what they want the new software program using the Moscow method. This
would help me understand where the common ground is and build off that.
In the interview I would use the 5 Ws and the 1H.
Projects face risks of failure quite often. There are many reasons to classify a
project as risky. The two I will highlight are the lack of appropriate funding and
stakeholders not giving the project proper support. First, funding a project can
sometimes be extremely complicated. Even if a business believes they have funded
a project fully, there are many costs that can creep up unexpectedly. One of the
major ones are change orders. For example, a company has several integrations, but
left an obscure yet important one out of the scope of work. Usually adding the
integration as a change order is not an issue, but most change orders come with an
additional cost. In addition to change orders, another situation that can unexpectedly
arise is the need for updated hardware or software. Perhaps their current system
runs on Windows 7, but the new build requires an upgrade to Windows 10.
Generally that would be an easy upgrade, but sometimes a new computer terminal
will also be needed to accommodate the operating system upgrade. Since lack of
proper funding can derail a project It is always wise to set aside additional funding.
If the money is not spent during the initial stages of the project it can be used for
annual maintenance or desired upgrades. The next risk is the lack of proper project
support by stakeholders. Stakeholders hold a great deal of power when it comes to
the success of a project. A lot of stakeholders are informal leaders and hold sway
over others. If they choose not to support the project, others will follow. this can
impact every part of the project from building to training to implementation. Each
of those pieces need to be appropriately supported in order to be successful.
The methods I would use to gather requirements would be interviewing stakeholders
and observation. Making sure all stakeholders have some involvement in the project
will go a long way to earning their support. Each stakeholder should have a voice,
since an administrator may have no idea what a front line user needs and vice
versa. In order to get a balanced view each position should be interviewed.
Observation is necessary since seeing how someone does their job can capture
information that was overlooked in interviews. Sometimes a user may do things out
of habit or muscle memory and not realize there is a functional requirement behind
it. This is also a helpful way to verify the information received in the interviews
makes sense and clarify any gaps in the information. Software engineering projects
are driven by business needs. There are many different risks that can arise in a
software engineering project. The common risks include project scope changes,
technical challenges, schedule and budget overruns. In this scenario, the scope of
the project poses a risk to the entire project because the partners are not in
agreement of what the scope of the project should be. With the undefined /
fluctuate scope, the project will take longer to complete thus increase in cost for
the project will occur.
To gather information for this retail store sale software, interviewing and
requirement workshops would be appropriate for this situation. Interviewing
stakeholders (store partners, store manager and sale associates) to gather information
about their needs and expectations for the software application. This method is
useful because the project team can obtain valuable insights that can be used to
build the features and functionality that are most important to the store for the
application. m Requirement workshops would bring the stakeholders together along
with the project team to discuss and identify the requirements for the software
application and working toward a detail information/scope of the project that would
be aligned with the needs of the store and its customers. I would have to say that
project risk management is a process of managing risks associated with projects. It
involves identifying, assessing, and mitigating risks. Some of the common types of
project risk are project scope change, budget change or resource availability change.
Risk management is an important part of project planning and execution to ensure
that risks are minimized as much as possible. When it comes to scope change the
stakeholders may have different ideas comparing to what you have for the project.
If you and the stakeholders can’t come to an agreement, then the project that you
plan to work with would not be completed. Therefore, you need to be able to
figure out what to discuss and how you and the stakeholders can come to an
agreement. It’s much easier to defend decisions and keep scope in check when
you’ve documented and agreed upon project deliverables before work begins says
.Knowing what risks to watch out for and how you’ll address them can go a long
way in easing anxiety for everyone involved in the project. Two ways that I would
use to gather requirements are document analysis and observation. Frequently
overlooked, document analysis is another highly effective technique for gathering
requirements. One of the best ways to understand what users truly need is to
observe them performing their daily tasks. By observing end users in the real
context in which they perform their tasks, you’ll gain a true understanding of what
they are up against and what improvements they need so they can perform better.
You’ll then be better able to specify a system that successfully reinvents users’
processes and grants them far greater productivity and usability, rather than simply
providing them an incremental improvement. Handling requirements is another way
of categorizing models. A Predictive Development model is an advancement of
thought on the needs before it is done. The design is based on the requirements of
the system and is used as a blueprint for the code to be written. Sometimes it's
hard to know what it needs and the materials to build it. Moreover, if the
developers aren't familiar with a technique to use, it is incompatible with the
program to work.An Adaptive Development model is a way to change the goals of
the project during development if it is necessary. This will reevaluate the changes
in the design's direction when the outset is not relevant enough. An example of this
is watching a detective show. It has a detective trying to find the killer, he/she has
the necessary tools, and each time he/she finds a clue, the direction becomes
updated.
A Sashimi Development model also known as the SashimI Waterfall phase is just
like the Waterfall model but it can overlap the steps. There are three types of
prototypes; throwaway, evolutionary, and incremental type. A throwaway is a study
of the system being tossed out once it is gathered and then the developer writes
the code from the beginning based on that system. An evolutionary prototype is a
type that describes the application's features. During the process, refinement of the
features is established, new additions are replaced, and the finished app is based off
of those new features. An incremental is creating a collection of other types from
the characteristics of their finished version, a combination of the applications. It is
easier for developers to work on individual pieces from separate prototypes. Feature-
Driven Development is both an iterative and incremental model where large teams
use risk, the value of customers, or the waste to guide their development process at
a higher level. The features listed in this build are popularized and become added.
It goes through five phases; develop a model, build a feature list, plan by feature,
design by feature, and then build by feature. Two partners which are unaligned will
derail the project, disappoint the customer, and ruin their reputations. The partners
should be able to communicate and collaborate effectively. These risks can be
unavoidable when the two partners have different visions, levels of experience,
expertise, and technical skills. One of the partners will dominate the other partner
and will hinder collaboration because they will have a different understanding of the
system requirements, tasks, and processes. Unaligned goals will be another risk for
the project. Both partners should have clear objectives for the project and the
deliverables at the end of the project.
One partner may have higher technical knowledge than the other partner. The more
experienced partner will lead in the development process, and this might inhibit the
learning experience of the other partner. To avoid these types of risks, both partners
should have similar levels of skills and experience so they can collaborate
effectively on the project.A lack of resources can cause significant problems for the
software project. Resources include the time, budget, and resources that are required
to complete the project. If one or both partners lack the required resources to
complete the project, they will have to make difficult sacrifices in order to complete
the project on time.Two methods I'd use to gather requirements for this project
would be interviews or surveys. Interviews could be done with key stakeholders to
get the requirements from different perspectives. A survey could be sent to
customers to learn more about the requirements for this project. I would use a
combination of both methods to collect information for my software project. I
would also use workshops to gather more information from these key stakeholders
and customers. In this situation there are two partners that want this sales software,
but they are unable to agree on what it should do. That in itself is a risk for the
project. One of the biggest risks to software development is the purpose and need
not being well defined. Be able to agree on what the program should do falls
under the purpose and need category and the stakeholder risk. With these partners
not agreeing they won't be able to execute the project wisely. They become
stakeholders in the project because they have the most interest in the project
succeeding and with them disagreeing it succeeding will become difficult. I would
start by doing stakeholder engagement because getting the partners to agree on what
the software should is important before any planning or development can be started.
Even, if it's just a very basic and simple idea to start with.This can be achieved in
many different ways by brainstorming, questionnaires, surveys, or presentations of
various ways that the software could work. Once we get them to agree then when
can start documenting requirements. The require are important because they can
define the various features that will be necessary, how many users will it need to
support at a given time, and even where and how they want to store customer
information. I would generally do more than what is described here, but I think this
is a good place to start. For this weeks discussion topic of two small sports
equipment store partners not agreeing on what the proposed sales software should
look like or do, I'd run away from this project! Just kidding, but what a mess. I
wonder how their brick and mortar store is functioning, or not functioning. One
partner must be carrying the load to avoid conflict. Anyway, back to the question.
One reason this project if classified as a risky project would be by definition of a
Waterfall model having clear and well defined objectives. If the model needs to
complete one step before moving to the next step, they would never get past the
first step of gathering what the software should look like and do. High level design
will never happen if the two partners can not give you a clear picture of what
they want. In the real world would it be possible to give them a example of past
working software's to agree upon? Another reason this would be a risky project
would be the possible conflict as the project continues or nears completion and the
partners see an example of their new sales software and not liking what they
see.So, two methods I would use to push this project along would be one on one,
or face to face interactions like brainstorming or group discussion. This would give
all parties some sence of urgency to get on the same page.
