Many business analysts focus their full attention on tasks related to specifying, modeling, verifying, and validating requirements. And in doing so, they often forget about a critically important aspect of the BA work:requirements prioritization... Since good prioritizing skills help teams deliver business value faster, it’s a key competency for business analysts to develop. An effective to get better at prioritizing requirements is to follow this 3-step approach during the requirements discovery process.
Business Requirements are central to Software Development Offshoring relationship. Requirements are not hard objects that can be put across as formulas or equations. Irrespective of the artifacts used in requirements communication, requirements remain soft objects subject to various interpretations that may leave many voids for assumptions. The purpose of this article is to investigate the challenges of requirements communication in Software Development projects.
It’s always the requirements fault! Whenever anything goes wrong with a software development project the requirements tend to be the scapegoat. It is a fact of life as a BA that at some point the requirements you write will be wrongly blamed for a mistake in the product. In reality, any oversight in the product is the responsibility of the entire development team. So what can the BA do to ensure they are not the convenient scapegoat for an issue with the product?
This article discusses a tool for documenting, categorizing, ranking and decomposing various types of requirements (business/user and solution). The business analyst (BA) can use this tool to capture high-level business and user requirements and then decompose them into solution requirements. In fact, the tool can be used multiple times and results strung together to provide forward and backward traceability of requirements through specification and test cases.
Large software systems have a few hundred to thousands of requirements. Neither are all requirements equal nor do the implementation teams have resources to implement all the documented requirements. There are several constraints such as limited resources, budgetary constraints, time crunch, feasibility, etc., which brings in the need to prioritize requirements.
Managers often ask me what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for requirements engineering. I’d love to give them a nice, tidy answer—but I can’t. As with so many questions in software, the correct answer is, “It depends.” This article explores some of the factors that influence what ROI an organization can expect from better requirements.
In this article we discuss the benefits of using an appropriate template as the vehicle for delivering requirements. We also cover how a review and approval process tailored to stakeholders can help create the alignment needed to move a project forward.
Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn't work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline. This article defines the requirements baseline and describes when to create one.
You can now create an instant app from your schema, and add spreadsheet-like expressions for business logic – a complete system in minutes. In this article, we review a new technology from Espresso Logic that makes your requirements – schemas and logic - into working software, and show an example of building a full application from scratch.
Tracking project status means comparing where you really are at a particular time against the expectation of what “complete” means for this development cycle. Monitor the status of just those functional requirements that were committed for the current release, because that’s the set that’s supposed to be 100 percent done before you declare success and ship the release.
How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.
Do “Agile”projects need written requirements? Let us answer this question in this short article. As you may know, more and more software development teams have been adopting “Agile”processes over the past decade or so. As you may also know, Agile development processes such as Scrum and XP emphasize “working software” over requirements documentation. Does this mean detailed, written requirements should be avoided in Agile projects?
In a new business analyst role, typically there will be a few types of requirements documents that are most commonly created... In this article, I’ll go through 7 steps you can take to write better requirements documentation or learn how to write a new type of requirements document.
brought to you by enabling practitioners & organizations to achieve their goals using: