CHAPTER 8 - STARING THE SOLUTION

   "" In which we bring the essence of business into the technological world of the 
       implementation.""

Designing the User Experience

It is the way of making products which people want to buy or use.The business ana-
lyst’s task here is to advise and to be an advocate for the business, as opposed
to attempting to design the experience himself.If no innovation occurs, then the
new product will be much the same as whatever it replaces. It is, of course,
important not to disrupt the essential requirements, but there are a number
of  things  that  you  can  do  to  make  a  more  innovative  and  acceptable  end 
product.

Remember that your clients measure your association incidentally
you react and interface with them—how you answer their inquiries, how
you bolster them, how you keep them educated about your items and
administrations. This reaction is the dynamic piece of associating with the client. Simi-
larly, recalling the client's name, inclinations, and past requests is
a latent method for staying associated.

Active  adjacent  systems  are  humans  who  can  interact  with,  or  participate 
in, the work. When active adjacent systems initiate events, they have some
objective in mind, and will collaborate with the work—provide data or bio-
metrics, respond to questions, indicate choices—until their objective is satisfied.

Cost Benefit and Risks

 Cost of your solution must be in proportion to the benefit it brings to the owner. The handling for
a business use case doesn't stop when it includes a helpful nearby framework. Indeed
in spite of the fact that the neighboring framework dwells outside the extent of the work, it tends to be considered some portion of the work due to its capacity to react right away. The twofold bolt demonstrates an extraordinary sort of adjoining framework, in which the information stream
"goes through" the neighboring framework. This sort of nearby framework neither starts occasions nor goes about as an outside sink for data streams.

Comments

  1. What is Innovation?
    • "Innovation is a process through which economic or social value is extracted from knowledge—through the creating, diffusing, and transforming of ideas—to produce new or improved products, services, processes, strategies, or capabilities." – Conference Board of Canada
    • Innovation is the process of making a product new or better. It is can also be the process of doing some service or action in a new way. In business, innovation also has to include the concept of improvement. To innovate in business is not just to do something differently, but to do or make something better.
    • Business innovation involves developing new products or improving existing technologies, processes, designs and marketing to solve problems, increase efficiency, reach new customers, and ultimately increase profits.
    Investing in innovation is critical to raising long-term economic growth. In this current economic climate, uncovering new sources of growth and leveraging the opportunities raised by global innovation are priorities for all stakeholders.
    Innovation in countries is measured by criteria such as:
    • levels of R&D spending (public and private)
    • numbers of scientific papers
    • venture capital investment
    • new patents, trademarks
    • high tech exports
    • cultural and creative exports
    • levels of Technology manufacturing/ density
    • productivity
    Factors such as political stability and safety, government effectiveness, rule of law and the ease of starting a business are considered to be innovation inputs in the Global Innovation Index - obvious necessities for innovation to flourish.

    ReplyDelete
  2. Assessing the Risks

    Normally enough, choosing a solution isn't simply a question of drawing a couple
    lines on process models and seeking the best. You have the duty to come up with ideally significant item—that is, ideally important to its proprietor. This infers the expense of your answer must be in extent to the advantage it brings to the proprietor. There is little point burning through $10 to build up the item if the advantage it brings is worth just $1.

    Normally, you couldn't want anything more than to burn through $100 and get $1 million in benefits, be that as it may, that is probably not going to occur. In this way savvy heads must win, and your appraisal of the expense of advancement and interruption must be sensible
    given the advantages that the new item will bring.

    So also, the risk must be with respect to the profit and cost. Risk in this case comprises of the probability of a potential issue turning into a genuine issue, together with the downside impact if the issue turns out to be genuine.(Mastering the requirements process, pg.194)

    In any business, including Skip the Dishes, risk assessment is a vital part whenever you are planing to release a new product and how much value it will have for the organization? In skip's case new product is a major update in the mobile application or website.

    ReplyDelete
  3. Product Use Case Scenarios

    The business analyst uses product use case (PUC) scenarios to communicate
    the intention of the automated product to the stakeholders. Naturally, the
    PUC scenario is not the only document available to you at this time. Even
    so, because it shows the functionality of the product, it is an easy document
    with which to convey your intentions to the stakeholders. We suggest that
    you present the PUC scenario to the stakeholders at some suitable meeting.

    Do not simply e-mail it to them—you need their feedback.
    We suggest this technique as one way of overcoming the problem inherent
    in many requirements specifications: They are difficult, if not impossible,
    to read. In many organizations, normal practice is to hand a copy of
    the requirements specification to the stakeholders, and ask them to sign it if
    they are satisfied that it describes the product they want developed. Unfortunately,
    this approach ignores the all-too-obvious fact that requirements
    specifications are rarely read by the business stakeholders.
    What does a PUC scenario look like? Not surprisingly, a lot like the BUC
    scenarios we discussed in Chapter 4. The difference is that the business
    use case contains all of the functionality that responds to a business event,
    whereas the corresponding product use case contains only that functionality
    to be implemented in the product.

    To begin, first identify the business events. Pick one of them and trawl to
    discover the functionality that responds to that event (the business use case).
    As a way of showing your understanding, write a business use case scenario
    for this event. When your stakeholders are happy with the scenario, determine
    how much of that BUC can be implemented as the product. Whatever
    that turns out to be becomes the product use case. Naturally, we suggest you
    describe it using a PUC scenario.

    To make decisions about the product boundary for this BUC, we need to
    define the constraints. We also need input from the stakeholders who understand
    the technical and business implications and the possibilities for the
    product boundary along with the business goals for the project.

    ReplyDelete

Post a Comment

Popular posts from this blog

Underlying competencies

Chapter 4-Business Use cases

Core Concepts in Business Planning