Chapter 7 – Understanding the real problem - posted by Liliane Castano Marino


According to chapter 7 of the Mastering the requirements process book, it is important to get the real problem by using abstraction – focusing on ideas rather than solutions.  That is, abstraction involves thinking about the essence of the subject by discarding the technological and physical components.

The Brown Cow Model:  Thinking above the line
 It is time to move above the horizontal line and go to the “What” section, where you can see the real business (essence of the business) without considering the solution.  Once you see that, you move to what you would like to be doing in the future (what-now and Future-what quadrants).  The reason for spending time above the line is to discover the real problem and avoid building solutions to the wrong problems.  So, the requirements discover task is to interpret what the stakeholder is saying and uncover its essence.

Swim Lanes Begone
It is about adding swim lanes to represent process models.  This is a way that business analysts sometimes accidently introduce implementation artifacts into the business problem.  When the swim lanes are removed from the model, it is far easier for the business analyst and stakeholders to see that activities do not have to be done in the same place and order in which they have always been done.

Solving the Right Problem
The real problem to solve is not a technological solution. Instead of focusing in the work to be improved, the project team often set out to solve the wrong problem by thinking about the product and the technology to be implemented.  Doing that, the project teams fail to see the larger world – the one that really contains the problem to be solved.

Moving into the Future
After understanding the current essence, it is time to move on to what you want the business to be and it is represented by the Future-What quadrant of the Brown Cow Model.   This quadrant involves questioning and improving the current business essence to make the business more effective, efficient and innovative.

Comments

  1. Chelsia Palta19 April 2020 at 01:29

    This comment has been removed by the author.

    ReplyDelete
    Replies
    1. Chelsia Palta20 April 2020 at 12:46

      Abstraction has proven to be a powerful tool for controlling the combinatorics of a problem-solving search. It is also of critical importance for learning systems. Abstraction occurs in this framework in the service of control decisions. If an impasse occurs because of a lack of knowledge about how to make a selection, the resulting search is performed abstractly.

      Delete
  2. Hassan Kamara23 April 2020 at 19:19

    I found that the concept of not trying to focus o the solution but to focus on ideas to be rather interesting. I believe the "above the line" section of the brown cow model was explained well in this blog, it continues the theme of not prematurely looking for a solution but instead diving further into understanding what the real underlying problems are. The swim lanes section proves to be a good way of making sure a BA doesn't accidentally introduce any unnecessary implementation artifacts.

    ReplyDelete
  3. Paramjeet Kaur Toor24 April 2020 at 18:44

    This is good information. I would like to add that like all the organization, Scotia bank also use Brown Cow model as it helps to identified the real problem that we are going to solve. It is good to spend more time on "What" as it provide the detail about problem not solution. So, for reaching out to solution, we must have a real problem because only then we will be able to find the right solution.

    ReplyDelete

Post a Comment

Popular posts from this blog

Chapter 8 - Starting the Solution by Harvinder Singh

  Chapter 8 Starting the Solution We are transferring from an abstract global to the physical international, from policy to technology, from problem to solution; from purpose to design: we have reached the closing quadrant of the Brown Cow Model, in which will be determined how we are going to enforce the essential business. With a solid know-how of the essence of the business, which means that the real trouble to be solved, it’s time to determine which components of that problem would advantage from being automated. The commercial enterprise analyst juggles many factors to determine the most appropriate product to build. Iterative Development Iterative development is a way of breaking down the software improvement of a large application into smaller chunks. In iterative development, feature code is designed, developed and examined in repeated cycles. With each iteration, additional functions may be designed, advanced and examined till there is a com...
Read more

Chapter 4- Business Use Cases - posted by Chelsia Palta

Understanding the Work  The product you intend to build must improve its owner’s work; it will be installed in the owner’s area of business and will do part of the work. It does not matter which kind of work it is commercial, scientific, embedded real-time, manual, or automated you always have to understand it before you can decide which kind of product will best help with it. Use Cases and Their Scope The term "use case" was coined by Ivar Jacobson back in 1987 as a way to describe an interaction between a system and a user of that system. Jacobson needed to break the system into smaller units, as he felt that object models were not scalable. Thus, to conquer the complexity and largeness of modern systems, he said it was first necessary to partition them into convenient chunks, and that these chunks should be based on the user’s view of the system. The Outside World Adjacent systems behave like any other systems: They contain processes and consume and/or...
Read more

Chapter 11 Non-Functional Requirements by Hassan

Non-Functional Requirements Non-Functional Requirements can be generalized as "what a product/system is supposed to be. these requirements tend to be qualities that the product should have and they should specify how well the product does what it does. the requirements should either make the product usable, fast, reliable, attractive or safe and they should describe the character/ the way the functions should behave. Look and Feel Requirements the look and feel requirements are key to the non-functional requirements and as a BA one must consider them for every project. These requirements can describe how a product/system's desired appearance, mood, spirit or overall style/ appearance. The look and feel requirements can further specify what the product/system intends to appear as and is not a detailed design of the product/system itself. The typical look and feel requirement should be simple to use, professional looking, attractive to its market, consistent with previ...
Read more