- As you learned in Wk 2, requirements are a fundamental component to any project. Depending on the SDLC applied, requirements can be written in different forms. For example, some requirements will be very technically focused (technical requirements) and are written in a manner that dictates what a stakeholder expects the system to accomplish. Another approach taken, often with Agile-run projects, is to create a user story. A user story focuses on different types of system users and outlines more of a workflow that organizations expect.
Review the Wk 2 Discussion – Project Requirements about what are considered well-written requirements.
The WeLoveVideo, Inc. project team met with the business owners last week in a structured requirements-gathering meeting. In this meeting, they discussed that the requirements should focus on certain users, such as customer support representatives and inside-sales representatives, as well as be geared toward the system supporting the job function.
Create 15 to 20 system requirements based on the scope of the project discussed in the requirements meeting. Ensure the requirements meet quality standards and are outlined in priority order. Provide a justification behind the prioritization within the document. You may use any Microsoft® program, such as Excel® or Word, to create the list of requirements.
Submit your assignment.
1. We are still talking about Customer Relationship Management system (CRM) – a CRM is used by customer service rep and inside-sales rep, not customers of WeLoveVideo.
2. Remember who we are talking to (business owners), and at what activity of system analysis and development we are at (requirement gathering).
3. Don’t forget we need priorities of these 15-20 requirements, and justifications for these priorities (why one or some requirements have higher priority than others).
Wk 2 Discussion
Well-defined business requirements are essential building blocks to any system project. If requirements are not written well, the input to design and development phases will be poor. However, well-written requirements will lead to a much better project outcome in relation to stronger designs and system solutions.
What are 2 key attributes to well-written requirements? How do these attributes impact the quality of the requirements? How might you assess system requirements based off these attributes?