Review Section Two Requirements Elicitation: At The Start ✓ Solved

Review Section Two Requirements Elicitation: At the start of

Review Section Two Requirements Elicitation: At the start of the requirements phase, involve business stakeholders, IT personnel, project designers, vendors, and finance personnel to brainstorm and define requirements. Develop a five-to-ten question elicitation questionnaire to illuminate problems, opportunities, and desired solution characteristics for the EiS project. Include evaluation criteria (cost, risks, schedule).

Paper For Above Instructions

Introduction and purpose. Requirements elicitation is a foundational discipline in software and systems engineering. For the Education Information Systems (EiS) project, which aims to provide a secure, scalable web-based information system for students and faculty with admin-led provisioning and two-factor authentication, a disciplined elicitation approach is essential. A well-constructed elicitation process aligns stakeholder expectations with technical feasibility, security requirements, data handling practices, and long-term sustainment. Following established practices in requirements engineering helps reduce later rework, mitigates risk, and supports traceability from stakeholder goals to system features (Sommerville, 2011; IEEE, 2011). This paper outlines a practical elicitation strategy, including stakeholder involvement, elicitation techniques, a sample questionnaire, evaluation criteria, and documentation practices rooted in foundational texts and industry standards.

Stakeholder identification and involvement. Successful elicitation begins with identifying the relevant stakeholders who can influence or are affected by the EiS system. Core groups include university executives and finance officers (governance and budget), IT security and infrastructure teams (authentication, access control, data protection), administrators (admin portal usage, role-based access), faculty and students (user experience, accessibility), and external vendors or consultants (integration and deployment). BABOK guidance emphasizes tailoring elicitation to stakeholder concern while ensuring diverse perspectives are represented (IIBA, 2015). Active engagement—through interviews, workshops, and joint validation sessions—helps surface tacit needs and constraints that are not readily apparent from documents alone (Sommerville, 2011).

Elicitation techniques and their application. A robust elicitation strategy combines multiple techniques to improve coverage and validity. Key methods include:

  • Interviews: Structured or semi-structured conversations with key stakeholders to uncover goals, constraints, and success criteria. Interviews are particularly effective for eliciting security requirements (2FA, data privacy) and administrative workflows (Sommerville, 2011).
  • Workshops and facilitated brainstorming: Collaborative sessions that surface shared understanding, prioritize requirements, and uncover potential conflicts early (Wiegers & Beatty, 2013).
  • Document analysis: Review existing policies, system documentation, and regulatory requirements to ensure alignment with compliance and governance constraints (IEEE, 2011).
  • Questionnaires and surveys: Targeted questions to collect broad input from large user groups, such as students across departments, while enabling anonymous feedback for sensitive topics (Weinberg & Gause, 1989).
  • Observation and shadowing: Directly observing current workflows to identify pain points and implicit needs in real contexts (Cockburn, 2001).
  • Prototyping and use case development: Early, lightweight representations of the admin portal and user interfaces to validate expectations and refine requirements iteratively (Sommerville, 2011).

Sample elicitation questionnaire. A five-to-ten item questionnaire provides a concise yet powerful starting point for elicitation. Example questions aligned with EiS goals include:

  1. What problems/issues does this project solve, and what measurable improvements would indicate success?
  2. What should the solution look like in terms of usability, performance, reliability, and navigability across devices (tablet, iPad, cell phone, laptop, and desktop)?
  3. Who are the primary users and what are their typical tasks within the system?
  4. What security and privacy requirements are non-negotiable (for example, two-factor authentication, data encryption, role-based access control)?
  5. What data must be stored, retained, and auditable, and for how long?
  6. What integration points exist with existing university systems (student information system, learning management system, payment gateways)?
  7. What regulatory or policy constraints must be respected (FERPA, data protection regulations, university governance)?
  8. What are the major technical or organizational risks that could delay deployment (budget fluctuations, vendor dependency, skill gaps)?
  9. What are the acceptance criteria or exit conditions for each major subsystem (e.g., admin portal, authentication module, data access layer)?
  10. How will success be measured post-deployment (user adoption, error rates, support ticket volume, data integrity)?

Evaluation criteria and success factors. The elicitation process should explicitly address how success will be judged. Typical criteria include cost of implementation, alignment with stakeholder goals, return on investment (ROI) in terms of improved student satisfaction and operational efficiency, security posture, and risk exposure. Questions should probe whether the project will solve the identified issues and what the consequences would be if requirements change or evolve during deployment. The plan should anticipate schedule constraints and potential impacts on milestones, enabling proactive risk management and contingency planning (IEEE, 2011; Leffingwell & Widrig, 2003).

Documentation, traceability, and sign-off. A robust requirements approach includes clear documentation and traceability from stakeholder statements to system features. A requirements specification should capture functional and nonfunctional requirements with rationale, constraints, and source. Traceability matrices link each requirement to its origin, design elements, test cases, and acceptance criteria, enabling effective change management and verification (Sommerville, 2011; IEEE, 2011). The BABOK standard reinforces the importance of stakeholder analysis, requirement life cycle management, and validation activities to ensure consensus and ongoing alignment (IIBA, 2015).

Contextual considerations for EiS. The EiS project presents specific considerations, including cross-device usability, scalable data storage for student and faculty records, and robust security controls. The admin portal will govern provisioning, roles, and access, with a need for comprehensive audit trails. Two-factor authentication is central to the security design, consistent with best practices in higher education IT and regulatory expectations (Gause & Weinberg, 1989). An elicitation plan that incorporates threat modeling, user experience testing, and early prototyping can reduce later rework and improve user acceptance (Cockburn, 2001).

Conclusion. A disciplined requirements elicitation strategy—grounded in established theories and standards—enables EiS to capture true user needs, align with governance and security requirements, and set a clear path for design, validation, and deployment. By combining a diverse set of elicitation techniques with well-structured documentation and traceability, the project can reduce ambiguity, manage risk, and deliver a system that meaningfully improves educational outcomes for students and staff alike (Sommerville, 2011; Wiegers & Beatty, 2013; IEEE, 2011; BABOK, 2015).

References

  • IEEE. (2011). IEEE Std 830-1998 (Revision of IEEE Std 830-1993) — IEEE Guide to the Software Requirements Specification.
  • Sommerville, I. (2011). Software Engineering (9th ed.). Boston, MA: Addison-Wesley.
  • Wiegers, K. E., & Beatty, J. (2013). Software Requirements (3rd ed.). Redmond, WA: Microsoft Press.
  • Cockburn, A. (2001). Writing Effective Use Cases. Boston, MA: Addison-Wesley.
  • Gause, D. C., & Weinberg, G. M. (1989). Are Your Lights On? How to Figure Out What the Problem Really Is. New York, NY: Dorset House.
  • Nuseibeh, B., & Easterbrook, S. (2000). Requirements Engineering: A Roadmap. Proceedings of the ICSE 2000.
  • IIBA. (2015). BABOK Guide v3. International Institute of Business Analysis.
  • Sommerville, I. (2011). Software Engineering (9th ed.). Addison-Wesley.
  • ISO/IEC/IEEE 29148:2011. Systems and software engineering — Systems and software requirements engineering.

Related Assignments