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. c 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. c 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.
