Business Analyst Blog with tips, techniques and resources for every BA.
The new normal of online working is bound to introduce new habits and opportunities for new learnings for business analysts looking to navigate the tides of the post-pandemic workplace.
Read MoreBusiness Analysts play a pertinent role in determining what functionality a system should or should not have. If you can ask these questions of every requirement, the implemented solution will have a higher possibility of acceptance:
Read MoreAs development practices change, so do the reasons why we write requirements and the level of detail we go into with Requirements Specification Documents. Even seasoned business analysts have at one point or the other asked themselves, “What level of detail is enough?”. The answer to this seemingly simple question is inseparably intertwined with the reason why we write requirements in the first place: so that they can be read, understood, and implemented.
Read MoreThis list of requirements prioritization techniques provides an overview of common techniques that can be used in prioritizing requirements.
Read MoreSelecting a Requirements Management Software should be done with as much care as when selecting any other software. You should identify which features are required for your project beforehand and assess if the tools currently available to you do not already meet your needs before hunting for requirements management solutions with all the bells and whistles you don't need.
Read MoreManaging change requests is particularly important in ensuring that the business does not spend its limited resources on changes that offer no real value at the expense of projects that can deliver real value and lasting benefits.
Read MoreThe Business Analysis: building better stakeholder relations through prototyping article, published on Justinmind blog, discusses 6 tactics that can help Business Analysts create good stakeholder relationships throughout the software development lifecycle. One of them is incorporating excitement requirements to increase stakeholder satisfaction.
Read MoreThis piece is a continuation of Why Do Business Analysts Miss Software Requirements? and provides more reasons why Business Analysts may miss out on key requirements necessary for system development.
Read MoreA project that ends with a deluge of change requests once operations have started can only signify one thing—missed requirements or unmet expectations. Requirements may be missed for many reasons on business projects. This article explores the reasons why requirements can end up as missed and some best practices to keep in mind for successful software implementation.
Read MoreRequirements development and management can falter at various points in a project, causing you to build your software on a faulty foundation of requirements. Prototyping can help a Business Analysis team avoid some of the most common mistakes in requirements development and management. Guest Post By Cassandra Naji.
Read MoreWhile a cruise ship captain is responsible for the vessel, its crew and the passengers, a facilitator is responsible for the outcome of the requirements elicitation event. Still, there are many similarities between a ship captain and an event facilitator:
Read MoreSoftware requirements and the decisions made relating to them, carry through from the point of conception until the product is working in the live environment. One of the key activities that need to be completed during software projects is assigning priorities to requirements.
Read MoreRequirements elicitation sessions typically start with the question, “How do things work?”. By gaining an understanding of what works and what the business rules are, analysts are better positioned to identify the business rules from which requirements may be drawn.
Read MoreRequirements are usually not cast in stone. Stakeholders gather insights and more knowledge of their true needs with time. This means that they can change their minds about requirements, no matter how late in the game. Requirements should therefore be managed proactively in anticipation of change.
Read MoreWhen sign-offs are sought without political undertones and with the right intentions, there are certainly benefits to be had. The sign-off process should be approached as an opportunity for discovery that allows stakeholders to ask questions and get clarification on their areas of concern. A huge benefit of obtaining sign-off on requirements is that it indicates stakeholders are aware of, and are committed to seeing the solution live and in action.
Read MoreRequirements Review Sessions or Structured Walkthroughs are designed to communicate, check and confirm requirements with stakeholders. During these sessions, participants are expected to ask and respond to questions, proffer suggestions and provide comments on the solution that is about to be implemented. To maximize the limited time you have with stakeholders, follow these key steps to ensure you get it right the first time.
Read MoreThis post was inspired by Donald Firesmith’s piece on Requirements Mistakes where he discussed the common mistakes that occur in requirements engineering. Keeping these mistakes in mind can help business analysts (regardless of their domain) develop improved requirements management processes that ensure the delivery of high quality requirements.
Read MoreNon-functional requirements are easy to overlook. This is most likely because stakeholders often assume that these requirements are given and go without saying. Missing requirements are harder to spot during requirements evaluation than poorly specified requirements and are usually detected further down the line when the system is in the testing phase or has already been deployed to thousands of users. They become even more expensive to fix if they are architecturally significant. For example, It is often difficult to include performance, safety and security features to an existing architecture - Donald Firesmith, Software Engineering Institute, U.S.A.
Read MoreI once worked on a project that involved a series of discussions and consultations on whether to build or buy software. After extensive analysis, the decision was made to build the system in-house. To get started however, we had to prove that it could be done. We did this through a proof of concept (POC).
Read MoreThere’s a world of information available on how to write “good” requirements. Good requirement writing must be learnt and continually practised in order to deliver good solutions. You can use the ideas in this post as a checklist for verifying your Requirements Specification Documents.
Read MoreThis business analyst blog contains practical insights into business analysis, software testing and business process management. I will be sharing business analyst tips, CBAP Certification tips, lessons learnt and insights into all the things I've learnt during my BA career.
