Software requirements Essay Example

steps for certain events, such as when a customer places an order either via telephone or through our website, when a driver completes a delivery, and when a driver reports for work. Additionally, the system should generate information at specific points in time, such as when it is time to create an end-of-day deposit slip, time to make end-of-week restaurant payments, or time to produce weekly sales reports. Any logical assumptions used in this case study should be stated.

Your task is to create a software requirements specification (SIRS) document. Your team will determine the requirements for the software development. This specification will be based on the activities carried out during the requirements development and management process and will form the main part of the project report. The SIRS document should be included in the appendix."The project deliverables should focus on the requirements engineering processes that should be undertaken throughout the product development cycle. The aims of this assignment are to understand the principal requirements engineering activities and their relationship, be introduced to several techniques of requirements elicitation and analysis, understand the importance of requirements validation and how requirements reviews are used in this process, understand why requirements management is necessary and how it supports other requirements engineering activities. The assessment mark is distributed as follows: 70% for group contribution and 30% for individual contribution. The task is to undertake the Requirements Engineering processes in the context of a given case study to produce a Software Requirements Specification (SIRS) document. The complete set of activities undertaken in the Requirement Engineering process should be documented and forms the main body of the project report. The

class will be divided into groups of three team members and the tasks undertaken for this project should be fairly distributed as reflected in the workload matrix.The suggested presentation format for this project emphasizes the importance of a structured and organized approach to Requirements Engineering. The minimum report format is as follows, with the mentioned preserved:

- Cover Page: The cover page should include the CIT Logo, Subject Title, System Name, Intake Title, Intake Code, Group Number, and Group Members' Names.
- Table of Contents: The table of contents should have the topic title and reference page number attached to each topic. It should encompass the areas of focus mentioned in the marking scheme.
- Introduction: The introduction should provide the project background, scope, aims, and objectives.
- Schedule Planning - Giant Chart: A Giant Chart should be created to represent the tasks and responsible group member(s) involved in the project schedule.
- Matrix: A matrix should be included to depict workload distribution.

Overall, this format provides a comprehensive structure for presenting the project report, ensuring clarity and organization.Areas of focus:

- Software requirements: Some definitions of requirements, the requirements engineering process, and requirements development and management.

- Requirements development processes: Elicitation, analysis, and specification validation.

- Requirements management processes: Requirements management procedures, tracing requirements and traceability procedure, and requirement management tools.

- Good requirements characteristics: Attributes of good requirements specification.

- Implementation of Requirements Engineering: Requirements Specification Document (SIRS).

Documentation Standards:

- Project documentation should be complete and at least of average standard in terms of language, layout, and flow.
- The contents of the project documentation should be appropriately structured.
- References should be accurate, relevant, and up to

date, using Harvard's Name System of Referencing.
- Diagrams/tables/graphs used in the documentation should be properly captioned.

What You Need To Hand In:

The documentation has to be word processed, printed on single-side A4 size paper with 1.5 line spacing (optional) and comb bound. The maximum number of pages should be 50. Your group has to present your research findings to the lecturer, and the presentation will be judged accordingly. (Note: Each group member has to be involved in the presentation.)

Your group must submit the group case study by the specified due date and time. Each group member will participate in the presentation, and individual marks will be assigned based on the final mark set. The workload matrix should show the percentage contribution of each team member for each required component and be signed off by everyone in the team. Late submissions will not be assessed unless there are extenuating circumstances.

Performance Criteria Grade Assessment Guidelines: In order to receive a passing grade, the answers should be legible, organized, and written in clear, understandable English. Students who exceed the word limit will be penalized. A score of 0-49% indicates a superficial analysis with a lack of concepts and language relevant to the subject. It may involve regurgitation of irrelevant textbook material and poorly expressed ideas. Many key issues may be ignored or misunderstood.

A score of 50-64% demonstrates some understanding of relevant models and concepts, with elements of an appropriate structure present. However, the analysis of issues may be limited. A score of 65-74% shows evidence of reading and research, as well as understanding and application of appropriate models and concepts. Key issues are

identified and analyzed, although there may still be restrictions at times. Some sources are acknowledged.

The assignment demonstrates evidence of wider reading, with effective interpretation of information and integration of ideas across the subject area. It also includes credible recommendations and a systematic approach to development and evaluation. Most sources are acknowledged and referenced using the Harvard system.

For marks between 75-79%, the arguments in the assignment are clear and convincing, showing confident integration of theory and practices. Referencing to sources is consistent using the Harvard system.

According to the marking scheme and performance criteria, group distribution of marks is based on the following criteria:

- Requirements Determination:
- 0-5 marks: Very few functions explained or some functions not clearly explained, leaving the audience confused.
- 6-10 marks: Some functions explained clearly, some not well explained. Several ambiguities in the explanation. No discussion about non-functional requirements.
- 11-15 marks: Most functions in the software clearly explained. Very few ambiguities in the statements. Some consideration of non-functional requirements with a limited explanation.
- 16-20 marks: All functions in the software clearly explained in detail. Explanation has no ambiguities and can be easily understood. Some explanation provided on non-functional requirements.The development processes for requirements validation are lacking in correct approaches and good practices. The project shows major limitations and a poor application of requirements engineering procedures. There is no referencing or adoption of good practices, and the specification document is unstructured and of little relevance to the subsequent phases of software development.

The procedures for elicitation, analysis, specification, and validation of requirements are poorly engaged with many errors or inappropriate approaches. Some good

practices are seen in requirements engineering, but there is little or no referencing. The SIRS template is adopted or defined, but its contents only partly reflect the requirements development processes for the subsequent phases of the software development life cycle. It is important to use correct procedures to conduct elicitation, analysis, specification, and validation of requirements.

Some good practices for requirements engineering are observed, with minor errors in requirements models/requirements specification. Some referencing is seen, and the SIRS template is adopted or defined. Some of its contents are relevant for the subsequent phase of the software development life cycle. There is clear documentation of the essential steps taken to elicit, analyze, specify, and validate requirements.The text adopts good practices from different practitioners and references them accordingly. It includes a professional analysis and model/requirements specification. It also adopts or defines an SIRS template and its relevant contents that reflect the information needed for the next phase of software development life cycle. However, the requirements management lacks in addressing most of the components as required and lacks consistency in approach. Although some procedures for requirements management were undertaken, they only partially addressed the required components. It is important to use correct procedures when conducting requirements management. There are some good practices for requirements management, but there are also minor errors present.