Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Conceptually, requirements analysis includes three types of activities:
(e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering.
determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.
Requirements may be documented in various forms, usually including a summary list and may include natural-language documents, use cases, user stories, or process specifications.
Large systems may confront analysts with hundreds or thousands of system requirements. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. These may include the development of scenarios (represented as user stories in agile methods), the identification of use cases, the use of workplace observation or ethnography, holding interviews, or focus groups (more aptly named in this context as requirements workshops, or requirements review sessions) and creating requirements lists.
Upon initial contact, a Codesyne representative will work with a prospect through multiple communications towards creating a project proposal, with overview, design and development summaries, including broad requirements, timelines, estimated cost and next steps. ERP Business Solution proposals would also include a detailed scope of ModuleBlocks pre-built deliverables, custom code additions and selected optional ModuleBlocks services (hosting, subscription, training, etc).
Once the project proposal is approved an introduction meeting occurs between decision makers for the client and Codesyne team to educate Codesyne’s production process, define roles and responsibilities, and establish order of priorities and expectations for quality, scope, time and cost (1-4). The priority order is required when an unforeseen obstacle or new requirement enters production and in order to maintain the established expectation (specific launch date) a compromise is required (reduce quality or scope, add cost).
After priorities and exceptions have been agreed to, a second meeting between client and Codesyne production leads is required to storyboard the project and clearly define requirements for production. Moderated by Codesyne’s project lead, using post-it notes will horizontally qualify project categories (epics) and vertically list functionality (stories) and actions (tasks) while projecting and problem solving potential future obstacles and opportunities for discussion. This process may require multiple sessions.
Between storyboard sessions, categories (epics), functionality (stories) and actions (tasks) will be entered into JIra, to create a production backlog and then projected into a sprint forecast to match the priorities and expectations until client lead sign-off. This may result in the project to be broken up into multiple releases (versions) to achieve and submitted to client decision maker for review. This road map will become the scope of work, project schedule and fee schedule exhibits within the contract agreement to proceed into full production.