Latest Requirements Buzz
Eliminating Ambiguity from Your RequirementsFrom a developer's standpoint, few things are more frustrating than having to make lots of calls and research to learn what to create because the requirements are ambiguous. From an analyst's view, few things are more frustrating than having your requirements misunderstood. Yet so often, requirements are ambiguous to their readers, despite the writer's best efforts.
Business Requirements Should Drive Technology InvestmentsA business-driven technology strategy articulates the capabilities required for the success of an organization. To align your business-technology investments with your business strategy, you should focus on the type of value you want to create
Decisions on business-technology investments require structured thinking about what the business wants to achieve. This clear understanding of business requirements dictates the business-technology plans and investments needed to execute the company’s business strategy.
The Path to Requirements ElicitationThe path to requirements elicitation is something that analysts are rarely taught. Everyone knows that it involves interviews and research, but within most organizations, exactly how the interviews and research should be conducted is nebulous.
Requirements Gathering - Scheduling ActivitiesRequirements gathering activities should be scheduled by your project plan like any other project related activities. If these activities don't track to the schedule, whether because the schedule isn't feasible or some other reason, it will cause all the dependant activities to slip. Once you've chosen your requirements gathering approach and the stakeholders you'll meet with to gather the requirements, you can schedule the meetings, or interviews, or other methods for soliciting the requirements.
12th Australian Workshop on Requirements EngineeringRequirements Gathering - Define Requirements AccuratelyThe requirements you capture must be stated in business terms, must be clearly stated, must be concise, and must be feasible. To ensure that requirements are clearly stated, you should have them proof read by someone external to the project (or at least someone not familiar with the requirements you've captured).
Business Analyst Lessons - Solid Requirements MatterA company with poor requirements practices is just asking for over-budget costs and regular failure, according to a new report by IAG Consulting. The report, entitled Business Analysis Benchmark, examined 110 enterprise technology projects at 100 companies to determine just how important project requirements really are.
Gathering Software Requirements - Identify the Right ApproversWe mentioned previously in this section that a Statement of Work (SOW) embedded in the contract for a project will serve as the master blueprint for your requirements. Although we haven't consistently stated this disclaimer everywhere in this section it should be understood that no requirement, no matter how you gathered it, no matter who contributed it, no matter who approves it, can be a part of the required product unless it's stated or implied in the SOW! Keep this fact in mind when you identify the approvers of your requirements.
4th International Workshop on Visualization in Requirements EngineeringTopics of interest include experience papers, formal methods, emerging technologies, best practices, research proposals, evaluations and comparisons that focus on visualization techniques for requirements engineering activities.
Documenting Requirements For Software Development ProjectsThere are various ways and means by which requirements for software development projects can be gathered and documented. Before you start documenting the requirements you might want to be sure if you have captured all the required information.