|
I believe that when when business analysis is limited to (or centred around) the software development lifecycle, it ceases to be about defining the needs of the business and instead supports the main need of the solution provider: deliver software to schedule, which should be a means and not an end in itself. […] Scott Sehlhorst (@sehlhorst) has written an excellent article titled Requirements vs Design – Which is Which and Why? Some of my own thoughts are in this post, but read Scott’s article first to get the context. Scott seems to gather the problems a business sees with its current model (e.g., […] I’m bumping this post because of some updates, as highlighted in green below. Note that this post relates to Pega 6.1 and was originally drafted in 2009. Some of you Pega Business Architects were wondering how the modelling techniques I use relate to Pegasystems’ Direct Capture of Objectives approach, so […] As an analyst, it’s not enough to know what your customer wants. It is essential to unearth what the customer needs and how the customer’s business will benefit by fulfilling that need. Customers are often the last to understand what their business truly needs, even when they have a clear idea […] Activity Diagram tutorial part 3 View more PowerPoint from Declan Chellar Related posts: System Use Case or Screen Flow? Using activity diagrams to model use cases What NOT to put in your Activity Diagram […] Just as functional requirements are traced from business need to implementation, data requirements should be traced to eliminate redundancy and ensure coverage. The following slideshow lays out my procedure for tracing data requirements. Tracing Data Requirements View more presentations from Declan Chellar Related posts: The Importance of Data […] Whenever I mention data modelling on a project, everyone seems to assume I am talking about database design. In my experience, on the vast majority of projects, both the Business and the service provider leave data modelling until they are at the screen design stage. At best, they might start modelling […] Junior requirements analysts sometimes have difficulty with how to document business rules for information systems, or indeed, with recognising them in the first place. I hope this short article helps. Some Definitions “A rule under which an organization operates. A policy or decision that influences a process step.” (Data […] Many requirements analysis specialists have little or no development or testing experience and this can lead them to forget what the real deliverable is. The purpose of requirements analysis is to provide a robust and unambiguous requirement so that architects and developers know what to build and testers know what to […] |