Software Requirement Specification (SRS) Tutorial and EXAMPLE | Functional Requirement Document

Summary

This video script by Dr. White offers a comprehensive tutorial on crafting a software requirement specification (SRS). It outlines the SRS's purpose, detailing functional and non-functional requirements, and its audience. The script guides through the SRS structure, including sections like introduction, overall description, business rules, and various requirement categories. Best practices for creating an effective SRS are highlighted, along with an example of an SRS for a university admissions department website, emphasizing the importance of clear documentation for successful software development.

Takeaways

• 😀 A software requirement specification (SRS) is a formal document that outlines the behavior and implications of a software application by detailing functional and non-functional requirements.
• 🔍 Functional requirements describe the solution capabilities and behavior under specific conditions, while non-functional requirements describe the performance or quality characteristics that a solution must have.
• 👥 The primary audience for an SRS includes the technical team, subject matter experts, testing teams, and other stakeholders involved in the development and approval process.
• 📚 The SRS serves as a blueprint for design and implementation by the technical team and as a communication tool between technical and business stakeholders.
• 📈 The structure of an SRS typically includes sections such as introduction, overall description, business rules, functional requirements, use cases, data requirements, external requirements, non-functional requirements, reporting requirements, and supplemental information.
• 📊 Business rules in an SRS are specific, testable directives that guide behavior, judgment, or decision-making, often emerging as constraints in the form of policies, guidelines, standards, regulations, or calculated formulas.
• 📝 Functional requirements should be system-agnostic to minimize design dependency on a specific application, and they are derived from stakeholder requirements.
• 📋 Use cases in an SRS describe the functionality in a system that allows the user to achieve a goal, detailing the relationship between actors and the solution.
• 🌐 Non-functional requirements (NFRs) cover aspects like availability, compatibility, performance, portability, reliability, scalability, security, supportability, usability, and localization.
• 📉 Reporting requirements in an SRS outline the reports that will be generated by the solution, including details like report title, headers and footers, layout, security and access, and report logic.
• 📚 Best practices for creating an SRS include developing a separate business requirements document, involving key stakeholders, enabling manageability, using a checklist, using visuals, and being clear and concise in language.

Q & A

What is the purpose of a Software Requirement Specification (SRS)?

A Software Requirement Specification (SRS) is a formal document that outlines the functional and non-functional requirements of a software application. It serves as a blueprint for design and implementation, guiding the technical team and acting as a communication tool between technical and business stakeholders.

What are the two main types of requirements discussed in the script?

The two main types of requirements discussed are functional requirements and non-functional requirements. Functional requirements describe the solution capabilities and behavior under specific conditions, while non-functional requirements describe the performance or quality characteristics a solution must have.

Who is the primary audience for an SRS?

The primary audience for an SRS includes the technical team, subject matter experts (SMEs), testing teams, and other stakeholders involved in approving the SRS. The technical team uses it to develop solution designs, SMEs review it for accuracy, and testing teams use it to develop test cases.

What is the significance of involving key stakeholders in the development of an SRS?

Involving key stakeholders ensures that all relevant perspectives and needs are considered, which helps in creating a comprehensive and accurate SRS. It also ensures that the requirements are testable and align with the expectations of all parties involved.

What are the common sections included in an SRS?

Common sections of an SRS include Introduction, Overall Description, Business Rules, Functional Requirements, Use Cases, Data Requirements, External Requirements, Non-functional Requirements, Reporting Requirements, and Supplemental Information.

How are functional requirements typically structured in an SRS?

Functional requirements should include the actor (usually the system), the action (a verb), the object (a noun), and the qualifier criteria if needed. They should be system agnostic to minimize design dependency on a specific application.

What is the role of use cases in an SRS?

Use cases describe the functionality in a system that allows the user to achieve a goal. They provide a narrative that describes the relationship between actors and the solution, detailing how the interaction works. Use cases can be particularly useful when functional requirements involve various scenarios.

What are some common elements included in the Data Requirements section of an SRS?

The Data Requirements section typically includes a logical data model, a data dictionary, and data acquisition and maintenance details. A logical entity relationship diagram (ERD) is commonly used for the data model, and the data dictionary provides detailed information about important business terms.

What are non-functional requirements (NFRs) and why are they important?

Non-functional requirements (NFRs) describe the performance or quality characteristics a solution must have to be effective and satisfactory to stakeholders. They are important as they form constraints on the solution, often being measurable and applicable to the entire solution or system rather than a single functionality.

What are some best practices for creating a complete and effective SRS?

Best practices include creating a separate business requirements document before formulating the SRS, involving all relevant stakeholders in the development process, structuring the requirements for manageability, using a checklist to ensure all criteria are met, using visuals to illustrate complex requirements, and being clear and specific in the language used.

Outlines

00:00

📝 Introduction to Software Requirement Specifications

This paragraph introduces the concept of Software Requirement Specifications (SRS) and their importance in defining the behavior and implications of a software application. It outlines the purpose of SRS, which is to serve as a blueprint for design and implementation, and as a communication tool between technical and business stakeholders. The paragraph also highlights the need for well-crafted SRS to avoid project failures and meet expectations. The audience for SRS includes technical teams, subject matter experts (SMEs), and testing teams. The main components of an SRS are also introduced, such as introduction, overall description, business rules, functional and non-functional requirements, use cases, data requirements, external requirements, reporting requirements, and supplemental information.

05:02

🔍 Detailed Breakdown of SRS Components

This paragraph delves into the specifics of each section within an SRS document. It explains the purpose of the introduction, which includes the project scope and the document's purpose. It describes the overall description section, which provides a high-level overview of the product, its functionality, users, operating environment, and any constraints or dependencies. The paragraph also covers business rules, functional requirements, and use cases, emphasizing the importance of clarity and traceability in requirements. Additionally, it discusses data requirements, external requirements, and non-functional requirements, which are critical for ensuring the software meets performance and quality standards.

10:02

📐 Best Practices for SRS Creation

The paragraph discusses best practices for creating an effective and complete SRS. It suggests developing a separate business requirements document before formulating the SRS to ensure stakeholder alignment on project scope and outcomes. The importance of involving key stakeholders, such as subject matter experts and developers, is emphasized to ensure the SRS is comprehensive and testable. The paragraph also recommends structuring requirements for manageability, using a checklist to ensure all criteria are met, employing visuals for clarity, and using clear, concise language to express requirements. An example of an SRS for a university admissions department website is provided to illustrate the application of these best practices.

15:08

🖋 Example SRS for University Admissions Department Website

This paragraph provides a detailed example of an SRS for a university admissions department website. It includes the project's purpose, scope, and the various sections of the SRS such as business rules, functional requirements, use cases, data requirements, external requirements, non-functional requirements, and reporting requirements. Each section is elaborated with specific examples relevant to the admissions department, such as student eligibility rules, appointment scheduling functionalities, data retention policies, and user interface specifications. The example serves to demonstrate how the SRS can guide the development and testing of a software solution.

20:11

🏆 Conclusion and Call to Action

The final paragraph concludes the video script by summarizing the importance of a well-defined SRS and encouraging viewers to apply the knowledge gained. It invites feedback and comments from the audience and promotes further business analysis and certification training available at the provided website. The paragraph ends with a positive note, wishing the viewers a productive and prosperous day, and signals the end of the tutorial with a friendly farewell.

Keywords

💡Software Requirement Specification (SRS)

SRS is a formal document used in software development that outlines the functional and non-functional requirements of a software application. It serves as a blueprint for design and implementation, guiding the technical team and acting as a communication tool between technical and business stakeholders. In the video, SRS is the central theme, with the speaker discussing its components, audience, and importance in ensuring that software projects meet expectations.

💡Functional Requirements

Functional requirements describe the capabilities and behavior of a software solution under specific conditions. They detail what the system should do, including the tasks it should perform and the information it will handle. In the script, functional requirements are emphasized as statements developed by decomposing stakeholder needs into system requirements, crucial for enabling the software to meet user expectations.

💡Non-Functional Requirements

Non-functional requirements define the performance or quality characteristics that a solution must possess to be effective and satisfactory to stakeholders. These requirements are often measurable and form constraints on the solution. In the video, non-functional requirements such as availability, compatibility, and reliability are mentioned as essential for ensuring the overall quality and effectiveness of the software.

💡Stakeholder

Stakeholders are individuals or groups who have an interest or involvement in the project and are affected by its outcome. In the context of the video, stakeholders are crucial in defining requirements, reviewing the SRS for accuracy, and approving the final document. Their needs and expectations are central to the development of the software.

💡Subject Matter Expert (SME)

A subject matter expert is an individual with in-depth knowledge in a specific field or area, often responsible for reviewing documents like the SRS for accuracy and completeness. In the video, SMEs play a vital role in ensuring that the SRS is technically sound and aligns with the project's goals.

💡Use Cases

Use cases are narratives that describe the interactions between actors and a system, detailing how a user achieves a goal through the system's functionality. They are used in SRS to illustrate specific scenarios and are essential for understanding how the software should behave in different situations. In the script, use cases are mentioned as a way to provide additional detail to functional requirements.

💡Data Requirements

Data requirements specify the data that the software needs to handle, store, and manipulate to perform its functions. This includes logical data models, data dictionaries, and data maintenance procedures. In the video, data requirements are highlighted as a critical section of the SRS, ensuring that the software can manage and process the necessary data effectively.

💡External Requirements

External requirements in an SRS describe the needs and specifications for interactions with other systems or components outside the solution itself. This can include user interfaces, software interfaces, and communication interfaces. In the script, external requirements are discussed to ensure that the software can integrate and function properly within its broader environment.

💡Non-Functional Requirements (NFRs)

NFRs are a category of requirements that describe the attributes or qualities of a software system, such as performance, reliability, and usability. They are distinct from functional requirements, which focus on what the system does. In the video, NFRs like availability, scalability, and security are discussed as essential for defining the overall quality and performance expectations of the software.

💡Reporting Requirements

Reporting requirements outline the specifications for the reports that a software system will generate. This includes the type of reports, their layout, logic, and sequencing. In the script, reporting requirements are mentioned as a section of the SRS that details how data will be presented and accessed, which is crucial for stakeholders who need to analyze or review the system's output.

💡Best Practices

Best practices are guidelines or methodologies that have been proven to be effective in achieving a goal. In the context of the video, best practices for creating an SRS include involving key stakeholders, structuring requirements for manageability, using a checklist, and employing visuals. These practices help ensure that the SRS is comprehensive, clear, and aligned with project objectives.

Highlights

The importance of defining well-crafted software requirement specifications (SRS) for successful software projects.

Explanation of what a software requirement specification (SRS) is and its role in outlining functional and non-functional requirements.

Differentiation between functional and non-functional requirements and their impact on software development.

Identification of the primary audience for an SRS, including the technical team, subject matter experts, and testing teams.

The significance of decomposing stakeholder requirements into system requirements for functional requirements development.

Components of an SRS, such as introduction, overall description, business rules, functional requirements, and more.

The role of an introduction in an SRS, including purpose and project scope.

Details on overall description, including product overview, general functionality, and user descriptions.

Discussion on constraints, dependencies, and assumptions that affect software solutions.

Business rules section explanation and its impact on software behavior and decision-making.

The crucial section of functional requirements and how to derive them from stakeholder needs.

Use case descriptions for detailing system functionalities and user interactions.

Data requirements section breakdown, including data models and data dictionaries.

External requirements for interfaces and how they enable proper software functioning.

Non-functional requirements (NFRs) categories and their importance in software quality.

Reporting requirements and their significance in outlining solution-generated reports.

Supporting sections of an SRS, such as glossary, appendix, and approvals/sign-off.

Best practices for creating effective SRS, including stakeholder involvement and use of visuals.

An example of a software requirement specification for a university admissions department website.

The process of obtaining stakeholder sign-off to ensure alignment and commitment to the SRS.

Transcripts

are you tired of never-ending software projects  that fail to meet expectations if so it's time for  

you to start defining well-crafted software  requirement specifications in this video  

we'll dive deep into creating a game-changing  blueprint for your software project stick around

hey Doc Squad Dr White here with the business  analysis doctor today I'm giving a detailed  

tutorial on creating a well crafted software  requirement specification but before we get  

started if you want more business analysis  training and tips be sure to subscribe to  

the page and turn on that notification Bell  with that said let's get started let's talk  

about what you'll learn first we'll look at  what a software requirement specification or  

SRS is then we'll look at functional and  non-functional requirements we'll discuss  

the primary SRS audience the main components of  an SRS software requirement specification best  

practices and then we'll look at an example  of a software requirement specification  

so what is a software requirement specification  this is a formal business analyst document that  

describes the behavior and implication  of a software application by outlining  

functional and non-functional requirements  functional requirements are statements  

that describe the solution capabilities  and behavior under specific conditions  

they also describe the information that the  solution will handle functional requirements  

are developed by decomposing stakeholder  requirements down to the various system  

requirements that will enable it non-functional  requirements describes the performance or quality  

characteristics a solution must have to be  effective and of adequate satisfaction to  

the stakeholders these requirements are usually  measurable and form constraints on the solution  

non-functional requirements generally apply  to the entire solution or system rather than  

a single functionality software requirements  are used to provide a detailed description of  

solution requirements it serves as a blueprint  for design and implementation by the technical  

team it's also used as a communication tool  between Technical and business stakeholders  

so who is the srs-4 the primary audience of the  SRS includes the following the technical team will  

use the software requirement specification as a  guide to develop solution designs and to build and  

implement the software solution properly decompose  functional requirements should provide enough  

detail for developers to unit test the code during  development the subject matter expert or Smee will  

be responsible for reviewing the SRS for accuracy  and completeness while other roles may be involved  

in approving the SRS they often rely on the smee's  knowledge for approval testing teams the quality  

assurance and user acceptance testing teams  will use the SRS as an outline for developing  

test cases these teams will also help ensure that  the requirements are testable during requirements  

review sessions while the structure of the  software requirement specification varies based on  

the needs of the organization and project the most  common sections of the SRS includes introduction  

overall description business rules functional  requirements use cases data requirements external  

requirements non-functional requirements  reporting requirements and supplemental  

information now let's look at each section  in detail the software requirement specific  

education introduction provides an overview of  the initiative and the document two key components  

of the introduction include the purpose and the  project scope the purpose describes the purpose  

of the SRS identifies the product for which it  is created and describes the intended audience  

for the document the Project's scope gives  an overview of the software that's specified  

in the document in relation to the general  business requirements including the business  

goals objectives and expected outcomes now let's  look at the overall description of the SRS this  

section provides a high level overview of the  product and describes the general functionality  

of the software it also describes the users of the  software the operating environment as well as any  

constraints dependencies and assumptions that  apply to the software the product perspective  

description describes the origin of the product  or solution within the context of the organization  

for example is it replacing or enhancing an  existing system or is it a brand new product it  

also describes the key in interfaces between the  solution and the larger system that it may be a  

part of a system context diagram is often helpful  to illustrate this user classes is a description  

of the characteristics needs and expectations  of the users who will be using and directly  

interacting with software this section will be a  subset of the project stakeholders the operating  

environment describes the environment the software  will operate in such as operating systems system  

version databases hosts servers and geographical  locations of the users constraints are the  

influencing factors that cannot be changed and  often create limitations or restrictions on the  

product or solution assumptions are influencing  factors that are considered to be true but has  

not been verified there are also conditions that  are true now but may not be true in the future  

these assumptions are confirmed or disproven  before making any decisions that they may  

impact dependencies are components of the solution  that depend on the completion of the internal or  

external project factors common dependencies may  be the implementation of requirements that are  

dependent on other requirements decisions to be  made resources funding or other constraints the  

SRS may include additional constraints  assumptions and dependencies that were  

not defined in the BRD as a result of being  discovered during requirement analysis the next  

section is software requirements business rules a  business rule is a specific testable and business  

driven directive that guides Behavior judgment or  decision making business rules generally emerge as  

constraints in the form of policies guidelines  standards regulations or calculated formulas  

this section includes a list of business rules  that impact the software a description of the  

business rule and an indication of the related  requirement that's impacted by the rule this is  

often Illustrated with a table or Matrix the next  section of the SRS is the functional requirements  

this is arguably the most important section of  the document and it outlines what the system is  

supposed to do and what task it should perform  there are various ways to present the functional  

requirements however one best practice is to  start with the stakeholder requirements the  

functional requirement is derived from and then  decompose it into functional specifications other  

approaches start with features or business rule  that drives the specification the structure of a  

functional requirement should include the actor  which will always be the system the action which  

is a verb the object which is a noun and the  qualifier criteria if needed a keynote about  

functional requirements is that they should  generally be system agnostic to minimize the  

design dependency on a specific application this  is why we use the system now let's look at SRS  

use cases a use case is a functionality in a  system that will allow the user to achieve a  

goal a use case description is a narrative that  describes the relationship between actors and  

the solution as well as the details of how the  interaction works there may be times when the  

functional requirements involve various scenarios  that in impact the outcome of the functionality  

use case diagrams and use case description may be  included to outline these scenarios in detail the  

main components of the use case diagram includes  the system name the system boundary box actors  

use cases Association relationships and goals  the main components of a use case description  

includes the use case name the associated function  requirement actors preconditions triggers post  

conditions flow of events and scenarios for  detailed tutorials on both of these use case  

techniques see the links in the description next  is the software requirement specification data  

requirements this section describes the data that  the software needs to handle store and manipulate  

to perform its functions the data that the system  will consume process and create will be outlined  

here common elements of this section may include  a logical data model a data dictionary and the  

data acquisition and maintenance a data model is  a visual representation of the solution systems  

data relationships it may be included in the SRS  to provide a high level overview of the system's  

data a logical entity relationship diagram  or ERD is commonly used for this purpose for  

a detailed tutorial on the ERD see the link  in the description the data dictionary is a  

list of important business terms with detailed  information or metadata about each of them this  

often includes a description of the business  term data types allowed values and any other  

information that needs to have an acceptable level  of consistency to be useful while the data model  

provides a high level overview of the system's  data the data dictionary provides a detailed View  

for more information on the data dictionary see  the link in the description data maintenance  

describes how data is received and maintained  within the solution this may include health and  

data is transitioned and updated how long  it's retained data verification protocols  

archive Cycles backup procedures data disposal  time frames Etc the external requirements in an  

SRS describes the requirements that are outside or  external to the solution itself but will interact  

with it to enable it to function properly key  external interfaces are user interface software  

interface and Communications interface user  interfaces specify each user interface within  

the solution including how users will interact  with the system the screens they will use their  

navigation experience what type of user inputs  are expected and the expected response or outputs  

the solution will provide software interfaces  describe the interfaces between the solution  

being specified and other software applications  or components such as operating systems databases  

web services or commercial Integrated  Systems communication interfaces Define  

the communication channels and formats required  for the solution to communicate with other systems  

including networks emails messaging systems and  other communication interfaces the next section  

of the software requirement specification is  non-functional requirements or nfrs which we  

defined earlier in the lesson there are various  categories of non-functional requirements here  

are some of the most common nfrs availability is  the extent to which the solution is accessible  

and operating when needed this is often expressed  in terms of the percentage of time the system is  

available compatibility is the degree to which  the solution operates effectively with other  

components in its environment such as one process  with another performance is the speed at which  

the solution performs its function in response to  other inputs with minimum Assumption of resources  

portability is the ease with which the solution  can be transferred from one operating environment  

to another reliability it's the extent to which  a solution is available and performance required  

functions under stated conditions before failing  scalability is the degree to which a solution can  

grow or handle increased workloads security is how  well the solution protects against unauthorized  

use modifications destruction or disclosure  supportability is how easy the solution is  

to install configure and maintain and the adequacy  of supporting and training documentation usability  

is the ease of which the user can learn to use  and navigate through the solution localization  

are the requirements related to local languages  laws currencies cultures and other geographically  

driven user characteristics next is the SRS  reporting requirements these requirements outline  

the reports that will be generated by the solution  if applicable this includes type of reports inputs  

layouts logic sequencing Etc the following are  the common elements of reporting requirements  

the description provides general information about  each report including report title purpose users  

and data resources the header and footer provides  specifications about the layout and printout of  

the report's header and footer sections that  apply to all reports listed further down the  

layout outlines the body of the report such as  Fields column and row names charts and graphs  

Etc a wireframe of the report would be helpful  here as well security and access describes who can  

access the report and outlines any limitations  among the various user groups report Logic  

specifies the general logic of the report such  as triggers rules calculations latency and any  

criteria that impacts the report generation  now let's look at the supporting sections of  

the software requirement specification these are  the additional sections that provide additional  

context background information or supporting  details that are relevant to the functional and  

non-functional requirements these sections can  vary based on project and organization comments  

supporting sections that may be included in the  SRS are as follows the glossary of term provides  

a common understanding of the terms that are  used in the software requirement specification  

this is especially critical when a term may have  different meanings for different stakeholders or  

if there are acronyms that need to be defined  for the stakeholders who may not be familiar  

with them the appendix includes any attachments  or links to additional information outside of the  

actual SRS that are relevant to the project such  as diagrams charts or tables and finally is the  

approvers in sign off section this section  includes the signatures of all stakeholders  

with decision making authority to indicate their  approval of the software requirement specification  

sign off ensures that all stakeholders are in  agreement with the requirements outlined in  

the document by obtaining the segment teachers  from the key stakeholders the project team can  

confirm that everyone is aligned and committed  to the specification at this point the SRS is  

ready to be used to guide development work and  testing efforts now let's look at some best  

practices for creating a complete and effective  software requirement specification create a  

separate business requirements document a separate  business requirements document should be developed  

and approved before formulating the SRS this helps  the business analysts ensure that all stakeholders  

agree on the scope and expected outcomes before  spending time analyzing detailed requirement  

involve key stakeholders involve all the relevant  stakeholders in the process of developing the  

software requirement specification this includes  subject matter experts who may be involved  

in outlining the use cases developers who may  assist in ensuring the requirements are properly  

decomposed or testers who can help ensure that the  requirements are testable by doing this you can  

ensure that everyone's needs are met debt and that  the SRS is fit for purpose enable manageability  

structure the requirements in a way that makes it  easy to change and update them without excessive  

impact to other components of the SRS also ensure  each proposed change can be traced to an existing  

requirement this is often facilitated with the  traceability Matrix use a checklist a requirements  

checklist helps the business analysts ensure  that all necessary criteria and quality standards  

are met for each functional and non-functional  requirement as well as the overall specification  

document use visuals use diagrams flow charts  and other visual aids to illustrate complex  

requirements or processes within the SRS this will  add Clarity and ensure that all stakeholders have  

a shared understanding be clear business analysts  need to use clear and concise language to express  

requirements in the software requirement  specification avoid jargon and ambiguity and  

and be specific about what the software should  do and Achieve use diagrams and examples to help  

clarify the requirements now let's take a look  at an example software requirement specification  

this is a project for the admissions Department  website for a university to start you would just  

include the name of the project the version  number date and I usually like to include the  

company logo on the document as well then we  have a revision history where you include any  

changes that are made to the document as they're  reviewed next is a typical table of contents

the first section is the introduction section  I've highlighted some key areas of the purpose  

and project scope so for the purpose we have  this software requirement specification outlines  

the functional and non-functional requirements  for at least 1.0 of the admissions Department  

website or ADW project the project scope says  that the admissions Department website will  

transition all applications and forms  to an online platform and establish an  

electronic user account for the website the  next section is the overall description for  

the description we have that the ADW project  is an enhancement to the existing Department  

of Education website that will transition  many of the administrative services  

the context diagram below illustrates the  system interfaces and external entities for the  

user class section we describe the users so for  example a student can either be an active student  

or prospective student the admissions staff will  have a passive interaction with the system and the  

administrator is responsible for managing and  maintaining the website next is the operating  

environment here I'm saying that the website must  operate correctly with the most updated versions  

of the following web browsers Windows Internet  Explorer Firefox Google Chrome and Safari for  

design and implementation constraints one of  the specifications is that the system must pull  

student information from current University  databases next is the assumptions which is  

that the website must be available 24 7 outside of  scheduled maintenance for dependencies I have that  

all applicable forms will need to be transitioned  to an online format before implementation  

the next section is the business rules as you can  see we have a business rule list which outlines  

the rule ID the rule definition the type and  impacted area so for admission one the business  

rule here is that the student must have a minimum  high school GPA of 2.7 on a 4.0 grading scale  

and the business rule type is eligibility the  impacted requirement is requirement 4.8 fr  

next is the functional requirements section  this is where you should probably be spending  

the most amount of time as you can see here  I have the functional requirements grouped  

by users so I have a student user group and an  admission staff user group so here I'm breaking  

down all of the stakeholder requirements from  the BRD into functional requirements so the  

stakeholder requirement here is that the student  must be able to schedule an appointment based on  

available days and time here I'm breaking down  the functional requirements for the stakeholder  

requirement so the functional requirement here  states that the system must display a calendar  

of available dates when the student selects  schedule from the appointment options another  

example is that the system must display available  time slots when the student selects any date from  

the calendar of available dates now let's move on  to the use case section when there are functional  

requirements that need to be described in more  detail or have various scenarios that need to  

be discussed you can incorporate use cases  to represent the additional details that are  

needed I'm outputting the various scenarios  that are related to the list of requirements  

above so I'm referencing them here this use  case includes the main path and Alternate  

flow and the exception flow you could include  as many use cases you need in the specification  

the next section is the data requirements here  I'm using an entity relationship diagram and a  

data dictionary to represent all of the key  data elements for this project so now we  

have the data maintenance requirements so one  example I have here is that the website must  

retain student appointment history for up to 365  days next we have the external requirements for  

user interface one of the requirements is that  the system must provide an FAQ section on each  

web page with common questions for software  requirements I have sections including the  

admissions portal the department portal and the  student portal so for the admission portal one  

of the requirements is that the system must  transmit all the online course enrollments to  

get Mission portal immediately to keep course  availability up to date for communication  

interfaces One requirement might be that the  system must send an email message to the student  

to confirm appointments scheduled online line so  now we have our non-functional requirements some  

of the nfrs that I've included are availability  requirements capability compatibility requirements  

reliability requirements scalability requirements  and localization so for availability requirement  

you might have that the system must be available  99 of the time outside of scheduled maintenance  

for compatibility I've got that the system must  be compatible with different operating systems  

such as Windows Mac OS Linux and mobile  operating systems like IOS and Android a  

reliability requirement might be that the system  must install any available software update nightly  

to remain up to date for scalability the system  must be able to handle a large amount of volume  

of concurrent users without affecting performance  or availability and for localization a requirement  

might be that the system must support local  date and time formats that are commonly used  

in the student's country or region now we have  the reporting requirement section some templates  

may include reporting requirements as part of  the data requirements but I like to keep them  

separate at the end because sometimes these  requirements are implemented much later than  

the actual solution so for each report you'll  have a list of requirements including report  

title headers and Footers specification rules and  conditions field order grouping totaling and maybe  

a sample so for the report title I would just say  the report title is student enrollments report  

for headers and photos I would say that the  report header must contain the report title  

patrons name and the date range specified for  special rules and conditions I might have that  

the report must receive a date range input to  generate results for special rules and conditions  

I'd specify that the report must receive a date  range input to generate results for field order  

I'd specify that the fields should be in the  following order including student ID student  

name enrollment date and student department  for grouping I'd specify that the report must  

allow for grouping by department for totaling  I might specify that the report must total the  

number of enrollments based on all enrollments  or filtered enrollments and generally a sample  

report will be helpful you could include it here  or you can include it as a part of the appendix  

so for glossary of terms I might have a list  of terms here so for example a prospective  

student is anyone who needs Services related  to the Department of Education but has not been  

admitted into the university for the appendix  I might have several attachments including the  

BRD the current state process map future State  process Maps the data dictionary um or maybe the  

report samples and then finally I would have my  approvals and sign off and of course these will be  

our decision-making stakeholders for the project  and once we get sign off the software requirement  

specification will serve as the blueprint for  our design discussions and documentation as well  

as a baseline for any requirement changes well  there you have it folks that's what you need to  

know to craft a well-defined software requirement  specification if you learned something new be sure  

to tell me about it in the comments I'd love to  hear your feedback also be sure to check out all  

the business analysis and certification training  we have for you available at the badoc.com thank  

you so much for watching have a productive and  prosperous day and I'll see you next time bye now