Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[Article] Why are Requirements so difficult to master?


Jimi Wikman
 Share

Recommended Posts

  • Owner

Requirements are very important. In fact I would say that 95% of all failed IT projects can be traced to a poor requirement process. This is baffling because requirements are really not that complicated and yet I see people fail in organization after organization.

After I started to look into the different flavors of Requirements I start to understand why things are so very hard to understand for many. There are such confusion about what type of work you should actually do, who you actually work for and what you actually should deliver.

So let us define what a requirement is first:

 

"A Requirement is a legal agreement between the requester and the performer."

 

That statement alone will surely get a few people raising their eyebrow for the simple reason that it does not fit in their job description. Again this baffles me that we have so many different work description for a single discipline. My only explanation is that people are confused on what different levels you work with requirements.

If we simply break down the three most common way of working I have seen: Facilitate, Investigate and Document. Then add it to the three common areas of work: Business, IT and translation between the two, then we can make a nice matrix. From there we can see what actual roles people have.

 

Requirement Areas.png

 

For me I think that anyone working with facilitating meetings as their primary function is a manager. Anyone who just document the need is a secretary. Those two types of "requirement analysts" I see frequently and in my opinion we should make sure that we call them for what they are so people do not think that this is requirement work.

In the investigative category it is common to work in all 3 areas depending on who you work for. Business analysts help business to define their need and IT analysts help IT define their need. This is however not requirements as their final product, but need. That comes BEFORE requirements. In this matrix we can see that the only role that actually work with requirements as the final product are the Requirement Analysts. This makes sense since the definition of requirements as a final product is:

 

"The outcome of a Requirement is a translation between need and realization of that need."

 

This is where many fail. I see many, many requirements that are nothing more than a granular break down of a need, but lacking the translation.  Many are often either to undefined and border on a business need, or other times I see technical specifications instead of the need. My theory is that people do not understand what requirements are and who they are for.

We can see this in the delivery of requirements as well. I do not know how many times I have seen people claiming to work with requirements simply dump a bunch of documents on the development team and move on to next project, or next iteration of the project. This way of working when you build walls and throw packages over it is NOT a proper way to work with requirements.

As we can see in the matrix above a requirement analyst sit between business and IT. There she function as a bridge between the two, translating need in both direction to ensure everyone understand and agree on what should be realized. This can only be done with active communication, person to person, and you never deliver a requirement, you make a handover.

I think that this is the key for making requirement processes work: handover and asking development and test to take over the responsibility of the requirement. To ask the most important question there is: "do you understand what business want and can you realize that need with the information you have been provided?" If the answer is no to that question, then you are not done with the requirement.

If you just understand your place in the requirement process and you understand what a requirement is, then the requirement process will be easy for you. If your organization understand that as well, then life will be great for everyone.

 

So do you still think requirements are difficult?


View full blog article

Link to comment
Share on other sites

  • Replies 0
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Similar Content

    • By Jimi Wikman
      From the movie "Pentagon Wars". Bradley Fighting Vehicle design and development. Any design engineer will love this scene.
    • By Jimi Wikman
      Jira tool manager with the task of stabilizing the system and setting up work processes for all teams within H&M. Responsible for several projects including cloud initiatives and coordination with other systems such as ServiceNow. Heavily involved in designing the build processes (requirements, development, design, deploy and test) for the process office. Responsible for the design and implementation of SAFe in Jira and the build processes. Responsible for a small team of Atlassian experts. Supported 400+ teams with Jira questions and training of work processes.
    • By Jimi Wikman
      Requirements in Jira has long been a wish for many Jira users. Many have tried it and many have failed because Jira is not designed to work with controlled requirements. Because of this I have always suggested to work with requirements in Confluence, but with RTM from Deviniti, I might change my mind about that.
      I am a certified requirements analyst and as someone who works in all positions in a development process I know the importance of good requirements. While good communication is key for a good workforce it does not remove the need for controlled requirements. In Jira you can setup requirements as part of a workflow or as a separate issue type, but the experience is far from controlled.
      When I saw RTM from Deviniti for the the first time I was intrigued. It looked very similar to older systems like HP QC (now Micro Focus Quality Center) in it's structure. I installed it on my Jira instance and have played around with it for a while now. So far I am very impressed, especially since Deviniti have confirmed that some of the things I miss are in their roadmap.
      Requirements & test management in Jira
      RTM comes with five main modules, plus a bunch of reports. The modules are all customizable so you can define what issue types you want to map with what module. This is great because that way I can map towards already existing issue types, or custom make new ones if needed. For Defects I can even map multiple issue types, which is great if you like me use both Defect and Incident. This is also possible for Requirements which is necessary for working with multiple types. In my setup I only have functional and non-functional requirements, but you can add more if you like.

       
      The RTM Requirements module
      This is the exciting part of RTM! Working with requirements in RTM feels just like in ALM or other older systems, but with the ease and great usability of Jira. You can quickly create a tree structure and rearrange the tree is easy and fast with drag and drop. Existing requirements can be imported using the import function that is located in the left column where the tree is under the three dots.
      You can customize the tree structure in the RTM configuration that is located under project settings. There you can select if you want auto numbering and if you want the issue number to be written out or not.
      While we still miss a few things (see below) this is really a great start. It is by far the best requirements app for Jira I have seen so far.

      The RTM Test Cases Module
      Test cases are reusable tests with test steps that you use in the test plans to perform tests. RTM is competing with some big shoes in the test department, but they hold up pretty good here. I like the configuration for the test steps that you have in the RTM configuration under project settings where you can modify the columns for the test steps. This allow me to define what columns I want with ease. You can also select what the starting status is, but right now you can not add or edit the standard statuses.
      As with all modules you can import existing test cases using the import function above the tree structure where you see the three dots.

      The RTM Test Plans Module
      Test plans are equally easy to create and manage. In the test plan you connect test cases and test executions to get the full overview of the test scope and result. In the overview of the test cases connected to the test plan you can change the order, create new test cases or add test cases.
      To me this gave a very good overview of the scope, what was actually tested and I have plenty of room to describe the test plan without cluttering things up.

      The RTM Test Executions Module
      The test executions module allow you to quickly execute test plans and you can structure them the same way as all the modules. You can re-execute test executions, which then create a new test execution that you can place in a folder directly. This is great for example smoke test that you want to run frequently.
      There are some things I think can be improved visually, but overall this works pretty well.

      The RTM Defects Module
      The Defects module give you an overview of the defects in the projects.  If you are adding RTM to an existing project where you already have defects, then you can easily import them using the import function. It is a bit hidden, but you find it in the left column under the three dots.

      The Good and The Bad
      There is not a whole lot to say on the negative side of this because it works very well. I tested this with Portfolio for Jira and the result is amazing. You easily get the structure you need for a full parent-child tree structure and the modules in RTM provides a great focus area for requirements and test.
      Version management
      What I miss are the version management that absolutely must be there. This is one of the things that are on the roadmap for the future. Hopefully this can tie into some form of approval process to better control changes. This is important for large organizations, but also for non-functional requirements that usually are global.
      Acceptance Criteria
      This is also a thing that is currently missing and also on the road map for future updates. If these could work the same way as the test steps work today, or maybe even having them as separate entities like test cases, then this would be amazing.  This would allow for really powerful connectivity between not just requirements and test, but also defects and requirements.
      Import from other projects
      One of the things I miss is the ability to import from other projects. This is especially useful for non-functional requirements that are often shared between many projects. I would like to be able to import these as read only so I can have them as part of the requirement structure, but not be able to edit for example legal requirements. I can make a requirement in the existing project and link for now, but I think import as read only would be a better solution.
      Quickfilters in Defects module
      The only thing I miss here is the possibility to add quick filters, just like in boards. This would allow me to better use this view based on my need. I found myself jumping to filters a few times to get a more focused view and with quick filters that would not be necessary.
      The Module Templates
      While the modules are not terrible in terms of visual they could improve a bit. Things are a bit cluttered and the tabs are not super obvious at first glance. Here I would like to see a slight update using Jira standards, but we also need templates to add custom data for example. Based of the structure with tabs I think it would be possible to use the standard view design and just split it in the different tabs for starters.
      Better integration with Confluence
      If I add a Confluence link directly into the issue itself, then it show up as just Wiki page. This is not very good as I want to see the name of the page so I know what page it is referring to.
      Other Apps support
      Right now I can't add other apps to the modules view, which is a bit of a problem for the requirements part especially. I often add designs using Invision prototypes and if that is not shown in the modules view, then I have to jump back and forth between the issue view and the module view. That is not good and I think this need to be added to the modules template designs.
      Test Executions UX and Visuals
      The test executions are a bit clunky when it comes to the UX. I find myself getting a bit lost as things happen without me being in control and I sometimes end up in the test issue view instead of the execution view. I would like to keep the execution summary in the header so it remain consistent and so I can come back to the execution overview instead of the issue view.
      The statuses are not tied into a workflow, which means that you need to skip back and forth to manage your test executions. A mapping in the settings would be nice so I can map execution statuses to workflow statuses. Also, there might be a good idea to separate statuses from resolutions to keep in line with Jira standard.
      Colorful folders
      This is just a cosmetic thing, but I like to be able to differentiate folders using colors and icons. This makes it a whole lot easier to quickly find the correct are, especially for large trees that often occur in requirements for larger systems. it would be very nice to have the option of selecting colors of the folders and special icing on the cake if I can select an icon as well. It would be easy to just use FontAwesome for example and allow the user to pick the icon from the font set.
       
      My opinion on RTM from Deviniti
      This is by far the most complete solution for a functional way of working with requirements and test in a controlled way. It still need some work here and there, but I will recommend this to all my clients as it stands today. Even without version management or dedicated sections for acceptance criteria it is still far, far better than what most people have today.
      When this product get more polished I think this will be one of the must have apps in pretty much every Jira instance.
      I like it. A lot.

      View full blog article
    • By Jimi Wikman
      As I am leaving the current project, due to the fact that I am leaving for another company, other people are taking over my duties and I get less and less involvement in the work that I used to hold together as the spider in the web.
      This is very difficult as I am used to be the one in the center of all things and now I am on the outside. The new team lead do things differently and the process of change always leave a residue of confusion and every fiber in my body just want to step in and "fix" things. 
      The thing is that there is nothing to "fix", it's just change and the fact that I no longer sit in the center of the project any more. The new team lead have things well under control and the project is doing just fine without me. 
      The realization that you really are not that important is both liberating an a bit sad. On one hand I am glad because it means that I have succeeded in making myself obsolete and the team no longer have need of my guidance. They work just fine without me following the processes and workflows we have built together.
      On the other hand I feel a bit like a parent no longer being needed by their children and they move from home. Just in reverse as I am the one leaving. It's a bit sad to realize that you will no longer be the one they come for when they need help or the one they turn to for advice and comfort.
       
      While this is a strange and sometime uncomfortable situation it is also a great opportunity to observe and learn from the new team lead and also to lift my gaze and look at things outside my part of the project.  It's quite interesting and it's a very good learning experience, especially when you can pick up on body language. I see so many things now that I have not yet had time to observe before and it give me a wealth of new insights.
      So I am in a position right now that feels a bit weird, mostly because I am not just leaving the project, but the company as well. It's also sad as I have to much time to think about how much I will miss my team and my co-workers when I leave. 
      Have you ever been in the same position and what did you learn from that?

      View full blog article
    • By Jimi Wikman
      UX design, visual design, interaction design, creative technologist, GUI designer, usability consultant, information architect. The titles are endless these days and as someone who work with all of these pretty much every day I am starting to wonder if we are breaking things down to much these days, or if it is actually necessary to get things done?
      10 years ago most of these titles were pretty uncommon, at least compared to the way they are used today. They still existed, they just were not as clearly defined and separated as they are today. Most just called themselves "designer" and that was pretty much ok.
      When I had my own design business there was no distinction between a visual designer or a UX designer for example because without the knowledge of one you can not do the job of another.
      Without knowing the information structure and the technical limitation of the platform I am designing for, I can not set the interaction design. Without the interaction design I can not set the UX and without the UX I can not set the visual design. It's not quite that linear as they all blend on multiple levels, but you get the idea.
      So for me these things are always connected and maybe that is why I never felt comfortable focusing on just one area. How can I best help a client if I do not understand the whole picture? How can I create a solution without understanding everything from psychology to visual principles to information architecture and interaction patterns in the different touch points in a customer journey?
      As the fields expand rapidly, just as they do for front end development, the information flow becomes almost unmanageable. Is this perhaps the reason why we see people that proclaim to be UX designers, visual designers or interaction designers? Or is it just that they still are "designers", but just focus on one area of expertise more than the other fields?
      Unfortunately I see a division, just like the division happening for the front end developers, where we have designers that put the creative power of the visual design as their only craft and others with the intellectual focus of interaction and psychology as a separate craft.
      I have been in projects where this division have worked fine and I have been in projects where this does absolutely does not work at all. It all depends on the people and the methodology where communication is always the key.
      As we dig deeper into the psychology of design and user behavior, for the web in general and e-commerce in particular, does this mean that it become to difficult to stay on top of the development in all these fields so a division of discipline is required?
      The tools we use suggest the opposite however and the borders between visual deign, interaction/UX design and even code becomes more and more blurred. So from a technical point of view we move towards where I was 10-15 years ago where you are doing just "design". 
      As of now I am not really sure what is the best way moving forward. Is it better to have very focused individuals that form teams to get the full width of the design process? Or is it better to have less focused individuals that can handle the full range of disciplines on their own? What does this mean for methodologies and work processes, does it matter at all?
      What are your thoughts on this matter? What direction do you think we are headed and how do you feel about that?

      View full blog article

×
×
  • Create New...