Hi to everyone 😀 Sun is out for last few days so there is many things to do outdoors, I will keep it short, well I will try 😀
System analyst is facing number of problems while developing a system. I’ll try to talk about the most common problems here. Lets get started 😀
1. No clarity in the scope of the business functions.
System Analysts recognize their role as one of defining the business solution boundaries– i.e., ensure the project scope definition aligns with the proposed solution to support the business needs. This is then translated into the Business Requirements Document. This BRD is approved and signed off by the customer as an agreement on the requirements. The challenge here is for the System Analyst to fully integrate the costs associated with satisfying the requirements with the investment to clarify the Business Function Scope right up front. Organizational issues add another layer of complexity in the BA’s ability to manage requirements. The pace of change in organizations is indicative of market pressures. Senior management pushes project teams to deliver projects quickly and more efficiently. Changing technology and the complexity of projects are other ongoing challenges. The System Analyst must work with the Project Manager to reduce the impact of these challenges during the System Requirements Analysis process. An effective way to do so is to capture challenges and document them in the Project Scope Statement. The resulting document will articulate the full scope requirements as reflected in the BRD and there will be a much greater understanding and clarity of the project’s scope among all stakeholders and business functions.
2. The requirements are not defined well.
The customer may not fully understand all of the project’s requirements at the beginning of the project. The customer may use imprecise language such as “ I guess, I want” or “Maybe we should consider” or may not fully articulate what is required. Requirements may be vague, incomplete and may not be specific enough to be measurable
This ambiguity often leads to products or services delivered to the customer that:
a) May be technically sound but fall short by not improving the business process.
b) Does not meet customer expectations
c) Results in increased cost—does not address the needs, so there will be another initiative, and another etc.
3. System analyst is asked for help too late.
The deliverables from the Business Requirements Document are further defined in the Project Scope Statement document. This is approved by the Sponsor and then used for project planning purposes. The Project Team breaks down the deliverables into tasks/activities and documents them into a Work Breakdown Structure. For this to all work in harmony, the System Analyst must be brought onto the project team at the very beginning of the project and remain as an integral part of the team until the project is completed and closed.
There is many more areas of the SDLC where the System Analyst will approach difficult situations, but as I said in the beginning I will keep it short 😀 Enjoy the weekend, and if you have any questions let me know 😀 Till the next time!!!