CMGT 555 Wk 2 DQ 1

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 requirements? How might you assess system requirements based off these attributes?

Respond to at least three of your peers. In your response, consider providing other impacts of the attributes listed. 

PEER 1

What are the 2 key attributes to well-written requirements?
Clear because all requirements should not contain unnecessary verbiage or information. They should be stated clearly and just; it will be better understood. Feasible because the requirement should be achievable within existing limitations such as time, money, and available resources.
How do these attributes impact the quality of requirements?
By following these two requirements, all the team members of developing projects and stakeholders will know precisely what is being requested without a doubt; also they will know that a project’s needs must be met no matter what.

PEER 2

A requirement attributes are important in ensuring information about the requirement gets understood by the right personnel. I think that key attributes to a requirement that is well written should be one that is making good use of its resources. Imaging developing a plan where the PM request too much resources and also not much resources. The requested resources should enough to ensure the project gets done with the least wasting of resources. The information I was looking at list Stakeholders as an attribute because it affects them should any changes be made to the requirement. I am adding another attribute which i think is important to the requirement and this is Risk. This is important because it list what is at stake if the requirement is not implemented.

Reference:
https://businessanalystlearnings.com/blog/2017/2/26/10-key-attributes-for-describing-software-requirements; Retrieved 4 April 2019.

PEER 3

The first attribute I would use in written requirements for a system project is to have no ambiguity about any of the terms used or roles each team member plays. There should be only one way to interpret the design and development phases on what the system should do. I have had security systems with dual authentication, truncate passwords and not give an error code because the field was not standardized length for the program. The second attribute would be to have consistent requirements that do not conflict with direct or indirect in describing the same functionality. An example of this would be when creating an account to have access to this company and it requires a phone number one for the account and the other to reset your password and get a verification code. The format is different for both, one has the area code in brackets and the other has none or one uses hyphens and the other does not.