6-1 Discussion Final System Requirement

docx

School

Southern New Hampshire University *

*We aren’t endorsed by this school

Course

510-R1041

Subject

Information Systems

Date

Apr 3, 2024

Type

docx

Pages

3

Uploaded by JusticeGoldfishPerson769

Report
Define what a final system requirement document is. A final system requirement document (FSRD) is a document that describes what a system can do, and how it will do it, both functionally and non-functionally. The system requirement document serves as a reference for the developers, designers, and stakeholders involved in system development. It is usually created after the completion of the initial system requirements phase and is crucial for the software development lifecycle. A well-structured system requirement document must: divide the issue into manageable chunks, and communicate design specifications, i.e. SRD must include sufficient information about software requirements to provide an effective design, provide feedback to the client or customer, and provide reference for testing and validation (Infectra, 2022). What sections does your final system requirement document include? According to IEEE standards, an SRD must address the following key issues: quality, security/privacy, functional capabilities, safety, performance levels, constraints and limitations, data structure/elements, reliability, and interface. The sections of a system requirement document are; stem requirement document or system requirement specification contains a description of the system requirements, functional requirements, technical requirements, acceptance criteria, assumptions, and constraints (JavaTpoint, n.d.). In the case of my system requirement document for the final project, the following sections were included: Requirement modeling – this includes the needs of the system deriving from the current challenges the client is facing and need resolved. Business process modeling – this section represents the workflow and logic of the business process. Data flow diagram – this section shows a traditional visual representation of how information will flow in the system. Data dictionary – this section serves as a reference for all stakeholders and ensures consistency and accuracy in the documentation. Object modeling - A system object, action, and its associated attributes are shown in this section Use case diagram – this section shows how each user will interact with the system. What do you believe are the most important sections, and why? I believe all sections of the system requirement document are equally important. However, the Requirement modeling section that outlines the specific requirements for the system such as the inputs, outputs, processes, performance, and controls plays an integral role for the other sections to be completed. Additionally, who is the audience of your final system requirement document? Are there multiple versions of the document to communicate to different audiences? The Final System Requirement Document is intended for a diverse audience, including stakeholders like developers, designers, project managers, quality assurance teams, and other individuals engaged in system development. Although there might not be distinct document versions, it is typical to customize the depth of detail and technical language to match the comprehension levels of various stakeholders.
The aim is to ensure efficient communication and collaboration among different teams working on a system (Wensel, 2003). References: Infectra. (2022, December 18). What are System Requirements? Inflectra. Retrieved January 17, 2024, from https://www.inflectra.com/Ideas/Topic/Requirements-Definition.aspx JavaTpoint. (n.d.). System Requirements Document - Javatpoint . www.javatpoint.com . Retrieved January 17, 2024, from https://www.javatpoint.com/system-requirements-document Wensel, S. (2003, October 13). Writing requirements documentation for multiple audiences . StickyMinds. Retrieved January 17, 2024, from https://www.stickyminds.com/article/writing-requirements-documentation-multiple- audiences Response Hello AFolabi, I enjoyed reading your post on the final system requirement document. The presentation of the final system requirement document will garner feedback on the functional requirements, non- functional requirements, and user interface. Feedback on function needs should be clear, specific, and in line with stakeholders’ expectations. Feedback on non-functionality needs should reveal any missing functionalities or ambiguities. Feedback should be measurable and in line with performance standards. To handle feedback, it is important to acknowledge and express gratitude for good feedback. If possible, incorporate positive aspects into other sections. Negative feedback should be approached with a constructive mindset. It’s an opportunity for improvement. Ask for clarification on specific concerns and address them with in-depth explanations or revisions (LinkedIn, 2023). Reference: LinkedIn. (2023, May 26). How do you handle feedback and criticism as a project manager? www.linkedin.com . Retrieved January 21, 2024, from https://www.linkedin.com/advice/1/how-do-you-handle-feedback-criticism-project Response 2 Hello Jordan, great post outlining the sections of a final system requirement document and their importance. When reviewing a final system requirement document, focus on specific sections and consider the feedback type for each. For functional requirements, focus on clarity and specificity;
negative feedback could highlight missing functionalities; for non-functional requirements focus on clarity and measurable requirements; negative feedback could focus on impractical criteria; for system constraints, focus on clear identification and feedback if constraints seem too restrictive; for external interface requirements, focus on clear descriptions of external interfaces; negative feedback could be based on ambiguities; and for documentation requirements, focus on a comprehensive approach; negative comments could be based on documentation burden. Efficient handling of feedback entails recognizing and valuing positive input while underscoring the significance of transparent communication. In contrast, when dealing with negative feedback, adopting a constructive approach is essential, considering it as a chance for enhancement and growth (LinkedIn, 2023). Reference: LinkedIn. (2023, May 26). How do you handle feedback and criticism as a project manager? www.linkedin.com . Retrieved January 21, 2024, from https://www.linkedin.com/advice/1/how-do-you-handle-feedback-criticism-project
Your preview ends here
Eager to read complete document? Join bartleby learn and gain access to the full version
  • Access to all documents
  • Unlimited textbook solutions
  • 24/7 expert homework help