Requirements Analysis is the process of understanding and capturing the customer needs and expectations from a proposed system or application. Requirement Analysis one of initial and very important step as success of project is largely depends of correct requirement capturing. Target team for Requirement Analysis is Project Manager, Project Lead, Senior Team Leads and Business Analyst. It's not a programming's or senior programmer's cup of tea but definitely one day you will reach at this designation so this is really important how to deal with this.
Why Requirement Analysis is Needed:
As mentioned earlier, requirement analysis is meant for capturing the correct requirements. If team is failed to identify the correct requirements then they may lead to development of project that was not desired by customer and then think, what will happen...Customer fires on company management, company management fires on Project Manager, PM fires on Leads and they ultimately fires on you with out even considering it was not you but those people who captured the requirement. Then late night working, overloading of task, hasty work, no QC and development with lots of BUG which will again fall back at you. So to make customer happy, just know at beginning why and what for he is paying.
Tools and Measures for Requirement Analysis:
Here is the list of tool used for Requirement Analysis:
Stakeholder interviews:
Stakeholder interviews are a common technique used in requirement analysis. These interviews may reveal requirements not previously envisioned as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements.
Joint Requirements Design:
JRD is conducte with customer, project manager and business analyst to elicit the specific design features to be implemented in satisfaciton of elicited requirements.
Prototypes/Wireframes:
Prototypes are Mockups of an application. Mockups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably.
Wire-frame is user inteface implemation that allow developers and team to understand what an end product interfact should be. wireframe jsut have user interface and navigation but it dosn't provide any business functionality.
Use cases:
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.
Software Requirements Specification:
A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints).
Requirements Traceability Matrix:
RTM is the tabular form document that helps in correlating two or more baseline documents and ensuring the correctness of requirements. RTM may link SRS, Use Case and Test Plan to check mutual consistancy between them.
Minutes Of Meeting:
MOM is also a very important part of requirement capturing. When you and team have client call and client ask for some change, then you must capture in MOM and send it back to client. By doing this you not only have proof of client statement but later when client ask why some changes was done, you can humbly say that he himself ask for this as mentioned in MOM and shared with him also on DD-MM-YYYY date.
Hope this will help you in identifying requirement analysis and capturing methodologies. Here I just provided basic reference. For more details, Please refer your old project document. I will provide you templates for MOM and SRS ASAP.
Thanks,
Mohit Singh
2 comments:
Hi mohit ... You have written very well .. but in this you have become a miser... please provide more regarding project management...
Thanx.
Thanks Deerendra for your valuable feedback . I will definitely add some more on Project Management...
Post a Comment