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

Search the Community

Showing results for tags 'requirements'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Atlassian

Categories

  • Personal
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Invision Community
    • E-Commerce

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Invision Community
  • E-Commerce
  • Affixes & Prefixes

Categories

  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Atlassian
  • Security
  • E-Commerce
  • Others

Categories

  • Thoughts
  • Debate
  • Health
  • Hobbies

Categories

  • Personligt
    • Åsikter
    • Humor
    • Spel
    • Träning
  • Allmänt
    • Internet
    • Program & tjänster
  • Intressant
    • Prylar
  • Professionellt
    • Management
    • Krav
    • Designs
    • Webbutveckling
    • Test
    • Atlassian
    • säkerhet
    • Förvaltning
    • Ehandel
    • Wordpress
  • Personligt_

Categories

  • Prologue
    • About This Book
  • The Tools
    • Jira Software
    • Confluence
    • Jira Service Management
  • The Inception Phase
    • Portfolio Management
    • Project Management
  • The Design Phase
    • Design as part of the Inception phase
    • Design as part of the Requirement phase
    • Working with design libraries
  • The Requirement Phase
    • Definition of Requirements
    • The four levels of Requirements
  • The Development Phase
    • Atomic design
    • Estimations
  • The Test Phase
    • The Definition of Test
    • Types of Test
  • The Operations Phase
    • Release Management
  • The Post Go-Live Phase
    • Incidents
    • Changes
  • Notes
    • My Muses
    • Research

Categories

  • Theme Building
  • Javascript Framework
  • CSS Framework
  • IPS: Pages
    • Database Templates
    • Block Plugin Templates
    • Page Templates
  • Custom Applications
  • Tips & Tricks

Categories

  • Professional
    • Consulting
  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
    • Hosting
    • Security
  • Interesting
  • Atlassian
  • Invision Community
  • E-Commerce
    • CRO
    • SEO

Categories

  • Shared Hosting
  • Virtual Private Server
  • Cloud Hosting
  • Dedicated Hosting
  • Co-Location
  • Hosting Services

Categories

  • Professional
  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
    • Security
  • Interesting
  • Atlassian
  • Invision Community
  • E-Commerce

Categories

  • Professional
  • Management
  • Design
  • Requirements
  • Development
  • Testing
  • Operations
  • Miscellaneous

Categories

  • Defects
  • Ideas
  • Development
  • ☑ Archive

Categories

  • Professional
  • Management
    • Agile
  • Requirements
  • Design
  • Development
    • Frontend
    • Backend
  • Testing
  • Operations
    • Security
    • Hosting
  • Interesting
  • Atlassian
  • E-Commerce
    • CRO
    • SEO
  • Invision Community

Categories

  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Testing
    • Operations
  • Interesting
    • Atlassian
    • Invision Community
    • E-Commerce
  • Miscellaneous
    • Fun
    • Games
    • Inspiration
    • Music

Categories

  • Jira Software Cloud Basics
    • Projects in Jira Software Cloud
    • Navigation in Jira Software Cloud
    • Boards in Jira Software Cloud
    • Filters in Jira Software Cloud
    • Dashboards in Jira Software Cloud
  • Jira Software Cloud User Guides
    • Working with Boards in Jira Cloud
    • Working with Filters in Jira Cloud
    • Working with Dashboards in Jira Cloud
  • Jira Software Cloud Project Admin Guides
    • Working with Project Settings in Jira Software Cloud
    • Working with People Settings in Jira Software Cloud
    • Working with Automation in Jira Software Cloud
  • Jira Software Cloud Admin Guides
    • Jira Software User Management
    • Jira Software Billing
    • Jira Software System
    • Jira Software Products
    • Jira Software Projects
    • Jira Software Issues
    • Jira Software Apps

Categories

  • Invision Community HTML Framework
  • Invision Community CSS Framework
    • Typography
    • Colors
    • Columns & Grid
    • Responsiveness
    • Forms
    • Datalists
    • Buttons
    • Messages
    • Miscellaneous
  • Invision Community JavaScript Framework
    • Invision Community UI Widgets
    • Invision Community Utilities modules
  • Invision Community CMS Pages
    • Invision Community Pages Basics
    • Invision Community Pages Templates
    • Invision Community Pages Tips & Tricks
    • Invision Community Pages Basic relationship
  • Invision Community Tips & Tricks

Categories

  • Design Guidelines
  • How to work with The Flexible Atlassian Setup
    • Portfolio Management
    • Visual Design
    • Requirements
    • Development
    • Test & Acceptance
    • Deploy & Release
    • Post GoLive Support
  • The Jira Software Cloud Setup
    • Introduction to the Setup
    • Issue Types
    • Issue Type Schemas
    • Workflows
    • Workflow Schemas
    • Screens
    • Screens Schemas
    • Issue Type Screens Schemas
    • Custom Fields
    • Field Configurations
    • Field Configuration Schemas
    • Permission Schemas
    • Notification Schemas
  • The Confluence System Documentation Setup
    • Introduction to the Setup
    • Architecture Section
    • Documents Section
    • Instructions Section
    • Quality Section
    • Requirements Section
    • Tecnical Documentation Section
    • Organization Section
    • Visual design Section

Categories

  • Professional
  • Management
    • Methodology
    • Leadership
  • Design
  • Requirements
  • Development
    • Frontend
    • Backend
  • Testing
  • Operations
    • Hosting
    • Security
  • Interesting
  • Atlassian
  • Invision Community
  • E-Commerce
    • CRO
    • SEO
  • Miscellaneous

Categories

  • HTML References
    • HTML Tags
    • Frontend Frameworks
  • CSS References
    • CSS Properties
    • CSS Methodologies
  • JavaScript References
    • JavaScript Objects
    • JavaScript Libraries
    • JavaScript Methodologies

Categories

  • Product Reviews
  • Company Reviews
  • Hosting Reviews
  • Personal Blog Reviews

Categories

  • Confluence Cloud Basics
    • Confluence Cloud Interface
    • Conflunce Cloud Spaces
    • Confluence Cloud Personal Space
    • Conflunce Cloud Templates
  • Confluence Cloud User Guides
    • Conflunce Cloud Macros
    • Conflunce Cloud Space Blog
    • Conflunce Cloud Space settings
    • Conflunce Cloud Space Pages
  • Confluence Cloud Admin Guides
    • Conflunce Cloud General Configurations
    • Conflunce Cloud Security
    • Confluence Cloud Look and Feel
    • Confluence Cloud Adminsitration

Categories

  • Tools
    • Professional
    • Management
    • Design
    • Requirements
    • Development
    • Testing
    • Operations
    • Interresting
    • Atlassian
    • E-Commerce
  • Methodology
  • Social Interaction
  • Areas of Expertise
    • Management
    • Design
    • Requirements
    • Development
    • Testing
    • Operations
    • Atlassian
    • E-Commerce

Forums

  • General
    • Open Forum
    • Support
    • Applications
  • Professional
    • Management
    • Requirements
    • Design
    • Development
    • Test / QA
    • Operations
  • Interesting
    • Atlassian
    • Security
    • E-commerce
    • Invision Community
  • Jobs
    • Looking for employee / consultant
    • Looking for Job / Assignment
  • Building The Site's Forums
  • Destiny 2's Discussions
  • The Journey's Discussions
  • Cinephilia's Topics
  • Diablo 4's Diablo 4 Topics
  • Shadownessence's Topics
  • sensory hyperreactivity's Topics
  • Wolcen's Wolcen Topics
  • Quality Assurance Heroes's QA Topics
  • Visual Studio Code's Forum
  • Adobe Illustrator's Adobe Illustrator Forum
  • Sketch Guru's's Sketch Topics
  • Requirements & test management in Jira's Topics
  • Microsoft Teams's Microsoft Teams Discussions
  • Figma's Figma Topics
  • Microsoft Planner's Microsoft Planner Topics
  • Psychology's Psychology Topics
  • Microsoft Word's Microsoft Word Topics
  • Microsoft Powerpoint's Microsoft Powerpoint Topics
  • WordPress Devs's Wordpress Topics
  • Ornamental Design's Ornamental Design Topics
  • Adobe Photoshop's Photoshop Discussions
  • Agile 2's Agile 2 Topics
  • Agile 2's Agile 2 Principles
  • Microsoft Outlook's Outlook Topics
  • My Book's Discussions
  • Outriders's Outriders Discussions

Categories

  • Jimi's Files
    • Curriculum vitae
    • Presentations
    • Certificates
  • Management
  • Requirements
  • Design
    • Fonts
  • Code
  • Test
  • Operations
  • Atlassian
    • Certificates of Excellence
  • Security
  • Ecommerce
  • Invision Power Services
    • JWSE Support Tickets
    • JWSE Task Management
  • Shadownessence's Files
  • WordPress Devs's Wordpress Files

Calendars

  • Project: JWSE Workboard
  • Project: JWSE Workboard
  • Community Calendar
  • Professional Events
  • Management Events
  • Requirement Events
  • Design Events
  • Development Events
  • Test Events
  • Atlassian Events
  • Operations Events
  • E-commerce Events
  • Invision Community Calendar
  • Destiny 2's Events
  • The Journey's Events
  • Cinephilia's premieres
  • Diablo 4's Diablo 4 Events
  • Agile 2's Agile 2 Events

Blogs

  • How to start your own blog
  • Sketch Blog
  • Building The Site's Blog
  • Destiny 2's Destiny 2 ramblings
  • The Journey's Stories
  • Diablo 4's Diablo 4 blog
  • Sketch Guru's's Sketch News
  • Requirements & test management in Jira's News
  • Agile 2's Agile 2 Blog

Categories

  • Movies
    • Action Movies
    • Adventure Movies
    • Animated Movies
    • Comedy Movies
    • Crime Movies
    • Drama Movies
    • Fantasy Movies
    • Horror Movies
    • Romance Movies
    • Sci-Fi Movies
    • Thriller Movies
    • Western Movies
  • TV Shows
    • Action TV Shows
    • Adventure TV Shows
    • Animated TV Shows
    • Comedy TV Shows
    • Crime TV Shows
    • Drama TV Shows
    • Fantasy TV Shows
    • Horror TV Shows
    • Romance TV Shows
    • Sci-Fi TV Shows
    • Thriller TV Shows
    • Western TV Shows

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 8 results

  1. When working with requirements, there can be situations where a requirement in one system can create new requirements on other systems. This can happen for example when you have requirements that touch on data that flow through integrations. For example, we can take a scenario where we have an e-commerce system that update their product data with a new field called hazardous products. This new field needs to be added to the integration to the transport system, since items marked as a hazardous product need special form of transportation. The way the system is set up, there is a message broker between the E-commerce system and the transport system that handle the transformation and flow of data between the systems. So we need to create a task for the E-commerce system to add the new data. We also need to add a task to update the integration and the integration contract between the E-commerce system and the message broker. These changes also require a task for the message broker and one for the transport system. So we will have three stories in Jira that will live in three different Jira Projects. This is not ideal and in order to keep track of the whole requirement so we also know when to conduct our end-to-end test, we create an Epic for this in the E-commerce Jira project. Then we connect the stories in the message broker Jira Project and the story in the transport Jira project. The E-commerce system own the requirement that is logged in their Confluence, and in this situation they are also responsible for driving the requirement towards the message broker and transport systems. Both the message broker and transport systems will update their documentation and their integration contract based on these new requirements, just as they would for any other requirement made to their system. If it makes sense for the dynamic between the three systems, the message broker and transport systems may add requirements to their Confluence as well.
  2. From the movie "Pentagon Wars". Bradley Fighting Vehicle design and development. One of the best illustrations on bad requirements and project management there is.
  3. 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.
  4. 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. 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?
  5. 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
  6. Requirements & Test Management for Jira MARKETPLACE.ATLASSIAN.COM Bring the whole software project right inside your Jira Decided to take this for a test run. Has anyone used it, or is currently using it?
  7. 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. 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
  8. 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.
×
×
  • Create New...