I have a hypothesis I want to explore:
Requirements Risk management could be a useful approach to requirements analysis, and lead to better requirements management.
High level the idea goes like this:
The purpose of this article is to introduce the topic of Requirements risk into the Requirements Management discussion. Feedback and commentary is welcome and can be provided at ModernAnalyst.com
Serious projects run risk management processes throughout their lifecycle. In fact, risk management is one of the nine knowledge areas of the PMI’s PMBOK, and one of several key processes in the (British) OGC’s P3M3 project, programme and portfolio management framework.
PM bodies obviously take risk management seriously, and it’s backed up by the academics. Studies are showing that a structured approach to risk management has a correlation with successful project delivery. Risk management is a vitally important part of project management.
I don’t need to explain the problem of requirements again. There are plenty of articles on the web about how poor project requirements management costs billions of dollars and lead to disappointment everywhere. Of course the best way to manage requirements is to put trained and experienced people on the job. Building up the knowledge areas and processes will also support the need to improve requirements management.
Author: Craig Brown Craig Brown works as a Project Manager and Business Analyst. He is an active contributor to Modern Analyst and runs his own blog called Better Projects.
"Good specifications will improve programmer productivity far better than any programming tool or technique." - Bryce's Law INTRODUCTION In terms of systems development, during the 1960's and early 1970's you were either a Systems Analyst or a Programmer. Period. At the time, there were substantially more analysts than programmers (at least a 2:1 ratio). This was due, in part, to the fact that computing was just coming into its own in the corporate world and there were still people around who could look at systems in its entirety. However, there was a screaming need for people to program computers and, as such, this became the boom years of programming. If you knew COBOL, Fortran, or PL/1 you could just about right your own ticket. Salaries were good, and you could intimidate your employer simply by what you knew (you had to commit something like murder to get fired). The emphasis on programming became so great that authors rushed out voluminous books to increase programmer productivity, hence the birth of the Structured Programming movement of the late 1970's, which was followed shortly thereafter by the CASE movement (Computer Aided Software Engineering).
Author: Tim Bryce
Business analysis is about more than software development. It can help business leaders to understand the business and develop resourcing, training and IT strategies. Through careful analysis of workflows and business processes you can identify opportunities for increasing efficiency and profitability. You can use business analysis techniques to help you identify potential processing bottlenecks or under-utilisation of costly resources.
Author: Jenny Blinman
Business analysts go by many titles one of them being Management Consultant. In this article, Tony Jacowski talks about the management consulting career.
Author: Tony Jacowski
Agile analysis is being spoken of more and more frequently in the world of business analysts. This form of analysis is becoming more and more popular as the next generation of business owners comes into play. It is a more hands on approach to the business analysis. There is more communication. Face to face discussions occur more frequently. E-mails and faxes are becoming few and far between. So what is agile analysis?
Author: Tony de Bree
The qualified business analyst wears many hats. He or she is a negotiator, a skilled listener, a motivational speaker, and a team leader. His or her title may include that of systems analyst, requirements analyst, or project manager. The business analyst may or may not have a degree in business analysis. He or she may not be able to write code. However, the business analyst is educated in the process necessary to produce the code. He or she may even come from an IT department. But what is it they do?
There are several key points one needs to understand before deciding whether or not to become a business analyst. You may be qualified to do the job you were hired to do. Yet is it the job you wanted to do? Some analysts find themselves locked in a cubical writing reports all day, only to find the report was not used or even read. They realize they are in a dead end job going no-where fast. This is not the usual dream one has when becoming a business analyst.
A use case study is designed to describe a situation in which the program is being utilized by the end user. It will tell a story of sorts describing how the program works and the input of the user. It does not tell how the program was developed. The details of the programming are not included in the use case study. You are trying to express the concept behind the creation.
The role of a business analyst can be very difficult. He or she must wade through the mass of information presented to determine the underlying problems. This information may or may not be correct. The business analyst much research to comprehend the true situation of the business. The information supplied to the business analyst is given from many perspectives. Opinions can influence how one perceives the related issues. At times, the opinions can add unrelated information which only complicates the role of a business analyst.
brought to you by enabling practitioners & organizations to achieve their goals using: