- Văn bản
- Lịch sử
C HA P T E R 1 0Documenting the req
C HA P T E R 1 0
Documenting the requirements
At the launch of a large project to build a commercial software company’s next-generation flagship product, a senior manager convened about 60 employees in a day long off-site “voice-of-the-customer workshop.” These employees worked with facilitators to generate ideas for the new product. The manager compiled the results of these brainstorming sessions into a 100-page document. He called this a requirements specification, but in fact it was nothing more than a pile of information.
The information from the brain dump by all these smart people wasn’t classified into various categories, organized logically, analyzed, or otherwise processed into anything that described a proposed software solution. Developers could not have gleaned what they needed to know about the new product from this massive collection of ideas. Certainly there were nuggets of valuable
requirements buried among all the chaff. But simply collecting raw ideas and needs into a long list isn’t an effective way to document and communicate software requirements.
Clear and effective communication is the core principle of requirements development—communication from people with needs to people who can conceive solutions, then to people who can implement and verify those solutions. A skilled business analyst will choose the most effective way to communicate each type of requirements information to each audience.
The result of requirements development is a documented agreement among stakeholders
about the product to be built. As you saw in earlier chapters, the vision and scope document contains the business requirements, and user requirements can be captured in the form of use cases or user stories. The product’s functional and nonfunctional requirements often are stored in a software requirements specification, or SRS, which is delivered to those who must design, build, and verify the solution. Recording requirements in an organized fashion that key project stakeholders can review helps ensure that they know what they’re agreeing to.
This chapter addresses the purpose, structure, and contents of the SRS. We will describe the SRS as being a document, but it doesn’t have to be in the form of a traditional word-processing document. In fact, documents pose numerous limitations:
■ It’s difficult to store descriptive attributes along with the requirements.
■ Change management is clumsy.
■ It’s difficult to retain historical versions of the requirements.
■ It’s not easy to subset out a portion of requirements that are allocated to a particular iteration
or keep track of those that were once approved but then deferred or canceled.
181
■ It’s hard to trace requirements to other development artifacts.
■ Duplicating a requirement that logically fits in multiple places causes maintenance issues.
As alternatives, you might store information in a spreadsheet (which has many of the same limitations as a document), a Wiki, a database, or a requirements management (RM) tool (see Chapter 30, “Tools for requirements engineering”). Think of these as different possible repositories or containers for requirements information. No matter what form of requirements repository you use, you still need the same kinds of information. The SRS template described here is a helpful reminder of information to collect and how you might organize it.
Not everyone agrees that it’s worth the time to document requirements. And on exploratory or highly volatile projects where you’re not sure what solution you’ll end up with, trying to keep up
with changes in the requirements details adds little value. However, the cost of recording knowledge is small compared to the cost of acquiring that knowledge or regenerating it at some point in the future. The acts of specification and modeling help project participants think through and precisely state important things that a verbal discussion can leave ambiguous. If you are 100 percent certain that no stakeholders will ever need a specific piece of information beyond the duration of their own short-term memories, then you don’t need to record it. Otherwise, store it in some kind of a group memory.
You will never get perfect requirements. Remember that you are writing requirements for certain audiences. The amount of detail, the kinds of information you provide, and the way you organize
it should all be intended to meet the needs of your audiences. Analysts quite naturally write requirements from their own point of view, but really they should write them to be most meaningful to those who have to understand the requirements and do work based on them. This is why it’s important to have representatives of those audiences review the requirements to make sure they’ll meet their needs.
Progressive refinement of detail is a key principle for effective requirements development. On most projects it’s neither realistic nor necessary to pin down every requirement detail early in the project. Instead, think in terms of layers. You need to learn just enough about the requirements to be able to roughly prioritize them and allocate them to forthcoming releases or iterations. Then you can
detail groups of requirements in a just-in-time fashion to give developers enough information so they can avoid excessive and unnecessary rework.
Don’t expect even the finest requirements documentation to replace ongoing discussions throughout the project. Keep the communication lines open among the BA, development team, customer representatives, and other stakeholders so that they can quickly address the myriad issues that will arise.
You can represent software requirements in several ways, including:
■ Well-structured and carefully written natural language.
■ Visual models that illustrate transfornational processes, system states and changes between
them, data relationships, logic flows, and the like.
■ Formal specifications that define requirements by using mathematically precise specification languages.
Formal specifications provide the greatest rigor and precision, but few software developers—and even fewer customers—are familiar with them. Most projects don’t demand this level of formality, but I’d certainly hope that the designers of high-risk systems like nuclear power plant control systems
use formal specification methods. Structured natural language, augmented with visual models
and other representation techniques (such as tables, mock-ups, photographs, and mathematical expressions), remains the most practical way for most software projects to document their requirements. The rest of this chapter addresses how you might organize the information in a software requirements specification. Chapter 11, “Writing excellent requirements,” describes characteristics of high-quality requirements and offers many suggestions for how to write them.
1. [Other requirements]
Define any other requirements that are not covered elsewhere in the SRS. Examples are legal, regulatory, or financial compliance and standards requirements; requirements for product installation, configuration, startup, and shutdown; and logging, monitoring, and audit trail requirements. Instead of just combining these all under “Other,” add any new sections to the template that are pertinent
to your project. Omit this section if all your requirements are accommodated in other sections. Transition requirements that are necessary for migrating from a previous system to a new one could be included here if they involve software being written (as for data conversion programs), or in the project management plan if they do not (as for training development or delivery).
Appendix A: Glossary
Define any specialized terms that a reader needs to know to understand the SRS, including acronyms and abbreviations. Spell out each acronym and provide its definition. Consider building a reusable enterprise-level glossary that spans multiple projects and incorporating by reference any terms that pertain to this project. Each SRS would then define only those terms specific to an individual project that do not appear in the enterprise-level glossary. Note that data definitions belong in the data dictionary, not the glossary.
Appendix B: Analysis models
This optional section includes or points to pertinent analysis models such as data flow diagrams, feature trees, state-transition diagrams, or entity-relationship diagrams. (See Chapter 12, “A picture is worth 1024 words.”) Often it’s more helpful for the reader if you incorporate certain models into the relevant sections of the specification instead of collecting them at the end.
Documenting the requirements
At the launch of a large project to build a commercial software company’s next-generation flagship product, a senior manager convened about 60 employees in a day long off-site “voice-of-the-customer workshop.” These employees worked with facilitators to generate ideas for the new product. The manager compiled the results of these brainstorming sessions into a 100-page document. He called this a requirements specification, but in fact it was nothing more than a pile of information.
The information from the brain dump by all these smart people wasn’t classified into various categories, organized logically, analyzed, or otherwise processed into anything that described a proposed software solution. Developers could not have gleaned what they needed to know about the new product from this massive collection of ideas. Certainly there were nuggets of valuable
requirements buried among all the chaff. But simply collecting raw ideas and needs into a long list isn’t an effective way to document and communicate software requirements.
Clear and effective communication is the core principle of requirements development—communication from people with needs to people who can conceive solutions, then to people who can implement and verify those solutions. A skilled business analyst will choose the most effective way to communicate each type of requirements information to each audience.
The result of requirements development is a documented agreement among stakeholders
about the product to be built. As you saw in earlier chapters, the vision and scope document contains the business requirements, and user requirements can be captured in the form of use cases or user stories. The product’s functional and nonfunctional requirements often are stored in a software requirements specification, or SRS, which is delivered to those who must design, build, and verify the solution. Recording requirements in an organized fashion that key project stakeholders can review helps ensure that they know what they’re agreeing to.
This chapter addresses the purpose, structure, and contents of the SRS. We will describe the SRS as being a document, but it doesn’t have to be in the form of a traditional word-processing document. In fact, documents pose numerous limitations:
■ It’s difficult to store descriptive attributes along with the requirements.
■ Change management is clumsy.
■ It’s difficult to retain historical versions of the requirements.
■ It’s not easy to subset out a portion of requirements that are allocated to a particular iteration
or keep track of those that were once approved but then deferred or canceled.
181
■ It’s hard to trace requirements to other development artifacts.
■ Duplicating a requirement that logically fits in multiple places causes maintenance issues.
As alternatives, you might store information in a spreadsheet (which has many of the same limitations as a document), a Wiki, a database, or a requirements management (RM) tool (see Chapter 30, “Tools for requirements engineering”). Think of these as different possible repositories or containers for requirements information. No matter what form of requirements repository you use, you still need the same kinds of information. The SRS template described here is a helpful reminder of information to collect and how you might organize it.
Not everyone agrees that it’s worth the time to document requirements. And on exploratory or highly volatile projects where you’re not sure what solution you’ll end up with, trying to keep up
with changes in the requirements details adds little value. However, the cost of recording knowledge is small compared to the cost of acquiring that knowledge or regenerating it at some point in the future. The acts of specification and modeling help project participants think through and precisely state important things that a verbal discussion can leave ambiguous. If you are 100 percent certain that no stakeholders will ever need a specific piece of information beyond the duration of their own short-term memories, then you don’t need to record it. Otherwise, store it in some kind of a group memory.
You will never get perfect requirements. Remember that you are writing requirements for certain audiences. The amount of detail, the kinds of information you provide, and the way you organize
it should all be intended to meet the needs of your audiences. Analysts quite naturally write requirements from their own point of view, but really they should write them to be most meaningful to those who have to understand the requirements and do work based on them. This is why it’s important to have representatives of those audiences review the requirements to make sure they’ll meet their needs.
Progressive refinement of detail is a key principle for effective requirements development. On most projects it’s neither realistic nor necessary to pin down every requirement detail early in the project. Instead, think in terms of layers. You need to learn just enough about the requirements to be able to roughly prioritize them and allocate them to forthcoming releases or iterations. Then you can
detail groups of requirements in a just-in-time fashion to give developers enough information so they can avoid excessive and unnecessary rework.
Don’t expect even the finest requirements documentation to replace ongoing discussions throughout the project. Keep the communication lines open among the BA, development team, customer representatives, and other stakeholders so that they can quickly address the myriad issues that will arise.
You can represent software requirements in several ways, including:
■ Well-structured and carefully written natural language.
■ Visual models that illustrate transfornational processes, system states and changes between
them, data relationships, logic flows, and the like.
■ Formal specifications that define requirements by using mathematically precise specification languages.
Formal specifications provide the greatest rigor and precision, but few software developers—and even fewer customers—are familiar with them. Most projects don’t demand this level of formality, but I’d certainly hope that the designers of high-risk systems like nuclear power plant control systems
use formal specification methods. Structured natural language, augmented with visual models
and other representation techniques (such as tables, mock-ups, photographs, and mathematical expressions), remains the most practical way for most software projects to document their requirements. The rest of this chapter addresses how you might organize the information in a software requirements specification. Chapter 11, “Writing excellent requirements,” describes characteristics of high-quality requirements and offers many suggestions for how to write them.
1. [Other requirements]
Define any other requirements that are not covered elsewhere in the SRS. Examples are legal, regulatory, or financial compliance and standards requirements; requirements for product installation, configuration, startup, and shutdown; and logging, monitoring, and audit trail requirements. Instead of just combining these all under “Other,” add any new sections to the template that are pertinent
to your project. Omit this section if all your requirements are accommodated in other sections. Transition requirements that are necessary for migrating from a previous system to a new one could be included here if they involve software being written (as for data conversion programs), or in the project management plan if they do not (as for training development or delivery).
Appendix A: Glossary
Define any specialized terms that a reader needs to know to understand the SRS, including acronyms and abbreviations. Spell out each acronym and provide its definition. Consider building a reusable enterprise-level glossary that spans multiple projects and incorporating by reference any terms that pertain to this project. Each SRS would then define only those terms specific to an individual project that do not appear in the enterprise-level glossary. Note that data definitions belong in the data dictionary, not the glossary.
Appendix B: Analysis models
This optional section includes or points to pertinent analysis models such as data flow diagrams, feature trees, state-transition diagrams, or entity-relationship diagrams. (See Chapter 12, “A picture is worth 1024 words.”) Often it’s more helpful for the reader if you incorporate certain models into the relevant sections of the specification instead of collecting them at the end.
0/5000
C HA P T E R 1 0Documenting the requirementsAt the launch of a large project to build a commercial software company’s next-generation flagship product, a senior manager convened about 60 employees in a day long off-site “voice-of-the-customer workshop.” These employees worked with facilitators to generate ideas for the new product. The manager compiled the results of these brainstorming sessions into a 100-page document. He called this a requirements specification, but in fact it was nothing more than a pile of information.The information from the brain dump by all these smart people wasn’t classified into various categories, organized logically, analyzed, or otherwise processed into anything that described a proposed software solution. Developers could not have gleaned what they needed to know about the new product from this massive collection of ideas. Certainly there were nuggets of valuablerequirements buried among all the chaff. But simply collecting raw ideas and needs into a long list isn’t an effective way to document and communicate software requirements.Clear and effective communication is the core principle of requirements development—communication from people with needs to people who can conceive solutions, then to people who can implement and verify those solutions. A skilled business analyst will choose the most effective way to communicate each type of requirements information to each audience.The result of requirements development is a documented agreement among stakeholders
about the product to be built. As you saw in earlier chapters, the vision and scope document contains the business requirements, and user requirements can be captured in the form of use cases or user stories. The product’s functional and nonfunctional requirements often are stored in a software requirements specification, or SRS, which is delivered to those who must design, build, and verify the solution. Recording requirements in an organized fashion that key project stakeholders can review helps ensure that they know what they’re agreeing to.
This chapter addresses the purpose, structure, and contents of the SRS. We will describe the SRS as being a document, but it doesn’t have to be in the form of a traditional word-processing document. In fact, documents pose numerous limitations:
■ It’s difficult to store descriptive attributes along with the requirements.
■ Change management is clumsy.
■ It’s difficult to retain historical versions of the requirements.
■ It’s not easy to subset out a portion of requirements that are allocated to a particular iteration
or keep track of those that were once approved but then deferred or canceled.
181
■ It’s hard to trace requirements to other development artifacts.
■ Duplicating a requirement that logically fits in multiple places causes maintenance issues.
As alternatives, you might store information in a spreadsheet (which has many of the same limitations as a document), a Wiki, a database, or a requirements management (RM) tool (see Chapter 30, “Tools for requirements engineering”). Think of these as different possible repositories or containers for requirements information. No matter what form of requirements repository you use, you still need the same kinds of information. The SRS template described here is a helpful reminder of information to collect and how you might organize it.
Not everyone agrees that it’s worth the time to document requirements. And on exploratory or highly volatile projects where you’re not sure what solution you’ll end up with, trying to keep up
with changes in the requirements details adds little value. However, the cost of recording knowledge is small compared to the cost of acquiring that knowledge or regenerating it at some point in the future. The acts of specification and modeling help project participants think through and precisely state important things that a verbal discussion can leave ambiguous. If you are 100 percent certain that no stakeholders will ever need a specific piece of information beyond the duration of their own short-term memories, then you don’t need to record it. Otherwise, store it in some kind of a group memory.
You will never get perfect requirements. Remember that you are writing requirements for certain audiences. The amount of detail, the kinds of information you provide, and the way you organize
it should all be intended to meet the needs of your audiences. Analysts quite naturally write requirements from their own point of view, but really they should write them to be most meaningful to those who have to understand the requirements and do work based on them. This is why it’s important to have representatives of those audiences review the requirements to make sure they’ll meet their needs.
Progressive refinement of detail is a key principle for effective requirements development. On most projects it’s neither realistic nor necessary to pin down every requirement detail early in the project. Instead, think in terms of layers. You need to learn just enough about the requirements to be able to roughly prioritize them and allocate them to forthcoming releases or iterations. Then you can
detail groups of requirements in a just-in-time fashion to give developers enough information so they can avoid excessive and unnecessary rework.
Don’t expect even the finest requirements documentation to replace ongoing discussions throughout the project. Keep the communication lines open among the BA, development team, customer representatives, and other stakeholders so that they can quickly address the myriad issues that will arise.
You can represent software requirements in several ways, including:
■ Well-structured and carefully written natural language.
■ Visual models that illustrate transfornational processes, system states and changes between
them, data relationships, logic flows, and the like.
■ Formal specifications that define requirements by using mathematically precise specification languages.
Formal specifications provide the greatest rigor and precision, but few software developers—and even fewer customers—are familiar with them. Most projects don’t demand this level of formality, but I’d certainly hope that the designers of high-risk systems like nuclear power plant control systems
use formal specification methods. Structured natural language, augmented with visual models
and other representation techniques (such as tables, mock-ups, photographs, and mathematical expressions), remains the most practical way for most software projects to document their requirements. The rest of this chapter addresses how you might organize the information in a software requirements specification. Chapter 11, “Writing excellent requirements,” describes characteristics of high-quality requirements and offers many suggestions for how to write them.
1. [Other requirements]
Define any other requirements that are not covered elsewhere in the SRS. Examples are legal, regulatory, or financial compliance and standards requirements; requirements for product installation, configuration, startup, and shutdown; and logging, monitoring, and audit trail requirements. Instead of just combining these all under “Other,” add any new sections to the template that are pertinent
to your project. Omit this section if all your requirements are accommodated in other sections. Transition requirements that are necessary for migrating from a previous system to a new one could be included here if they involve software being written (as for data conversion programs), or in the project management plan if they do not (as for training development or delivery).
Appendix A: Glossary
Define any specialized terms that a reader needs to know to understand the SRS, including acronyms and abbreviations. Spell out each acronym and provide its definition. Consider building a reusable enterprise-level glossary that spans multiple projects and incorporating by reference any terms that pertain to this project. Each SRS would then define only those terms specific to an individual project that do not appear in the enterprise-level glossary. Note that data definitions belong in the data dictionary, not the glossary.
Appendix B: Analysis models
This optional section includes or points to pertinent analysis models such as data flow diagrams, feature trees, state-transition diagrams, or entity-relationship diagrams. (See Chapter 12, “A picture is worth 1024 words.”) Often it’s more helpful for the reader if you incorporate certain models into the relevant sections of the specification instead of collecting them at the end.
about the product to be built. As you saw in earlier chapters, the vision and scope document contains the business requirements, and user requirements can be captured in the form of use cases or user stories. The product’s functional and nonfunctional requirements often are stored in a software requirements specification, or SRS, which is delivered to those who must design, build, and verify the solution. Recording requirements in an organized fashion that key project stakeholders can review helps ensure that they know what they’re agreeing to.
This chapter addresses the purpose, structure, and contents of the SRS. We will describe the SRS as being a document, but it doesn’t have to be in the form of a traditional word-processing document. In fact, documents pose numerous limitations:
■ It’s difficult to store descriptive attributes along with the requirements.
■ Change management is clumsy.
■ It’s difficult to retain historical versions of the requirements.
■ It’s not easy to subset out a portion of requirements that are allocated to a particular iteration
or keep track of those that were once approved but then deferred or canceled.
181
■ It’s hard to trace requirements to other development artifacts.
■ Duplicating a requirement that logically fits in multiple places causes maintenance issues.
As alternatives, you might store information in a spreadsheet (which has many of the same limitations as a document), a Wiki, a database, or a requirements management (RM) tool (see Chapter 30, “Tools for requirements engineering”). Think of these as different possible repositories or containers for requirements information. No matter what form of requirements repository you use, you still need the same kinds of information. The SRS template described here is a helpful reminder of information to collect and how you might organize it.
Not everyone agrees that it’s worth the time to document requirements. And on exploratory or highly volatile projects where you’re not sure what solution you’ll end up with, trying to keep up
with changes in the requirements details adds little value. However, the cost of recording knowledge is small compared to the cost of acquiring that knowledge or regenerating it at some point in the future. The acts of specification and modeling help project participants think through and precisely state important things that a verbal discussion can leave ambiguous. If you are 100 percent certain that no stakeholders will ever need a specific piece of information beyond the duration of their own short-term memories, then you don’t need to record it. Otherwise, store it in some kind of a group memory.
You will never get perfect requirements. Remember that you are writing requirements for certain audiences. The amount of detail, the kinds of information you provide, and the way you organize
it should all be intended to meet the needs of your audiences. Analysts quite naturally write requirements from their own point of view, but really they should write them to be most meaningful to those who have to understand the requirements and do work based on them. This is why it’s important to have representatives of those audiences review the requirements to make sure they’ll meet their needs.
Progressive refinement of detail is a key principle for effective requirements development. On most projects it’s neither realistic nor necessary to pin down every requirement detail early in the project. Instead, think in terms of layers. You need to learn just enough about the requirements to be able to roughly prioritize them and allocate them to forthcoming releases or iterations. Then you can
detail groups of requirements in a just-in-time fashion to give developers enough information so they can avoid excessive and unnecessary rework.
Don’t expect even the finest requirements documentation to replace ongoing discussions throughout the project. Keep the communication lines open among the BA, development team, customer representatives, and other stakeholders so that they can quickly address the myriad issues that will arise.
You can represent software requirements in several ways, including:
■ Well-structured and carefully written natural language.
■ Visual models that illustrate transfornational processes, system states and changes between
them, data relationships, logic flows, and the like.
■ Formal specifications that define requirements by using mathematically precise specification languages.
Formal specifications provide the greatest rigor and precision, but few software developers—and even fewer customers—are familiar with them. Most projects don’t demand this level of formality, but I’d certainly hope that the designers of high-risk systems like nuclear power plant control systems
use formal specification methods. Structured natural language, augmented with visual models
and other representation techniques (such as tables, mock-ups, photographs, and mathematical expressions), remains the most practical way for most software projects to document their requirements. The rest of this chapter addresses how you might organize the information in a software requirements specification. Chapter 11, “Writing excellent requirements,” describes characteristics of high-quality requirements and offers many suggestions for how to write them.
1. [Other requirements]
Define any other requirements that are not covered elsewhere in the SRS. Examples are legal, regulatory, or financial compliance and standards requirements; requirements for product installation, configuration, startup, and shutdown; and logging, monitoring, and audit trail requirements. Instead of just combining these all under “Other,” add any new sections to the template that are pertinent
to your project. Omit this section if all your requirements are accommodated in other sections. Transition requirements that are necessary for migrating from a previous system to a new one could be included here if they involve software being written (as for data conversion programs), or in the project management plan if they do not (as for training development or delivery).
Appendix A: Glossary
Define any specialized terms that a reader needs to know to understand the SRS, including acronyms and abbreviations. Spell out each acronym and provide its definition. Consider building a reusable enterprise-level glossary that spans multiple projects and incorporating by reference any terms that pertain to this project. Each SRS would then define only those terms specific to an individual project that do not appear in the enterprise-level glossary. Note that data definitions belong in the data dictionary, not the glossary.
Appendix B: Analysis models
This optional section includes or points to pertinent analysis models such as data flow diagrams, feature trees, state-transition diagrams, or entity-relationship diagrams. (See Chapter 12, “A picture is worth 1024 words.”) Often it’s more helpful for the reader if you incorporate certain models into the relevant sections of the specification instead of collecting them at the end.
đang được dịch, vui lòng đợi..
C HA PTER 1 0
Ghi chép các yêu cầu Tại buổi ra mắt của một dự án lớn để xây dựng sản phẩm chủ lực thế hệ tiếp theo của công ty phần mềm thương mại, một nhà quản lý cấp cao đã triệu tập khoảng 60 nhân viên trong một ngày dài off-site "voice-of-the-khách hàng xưởng . "Những nhân viên làm việc với hỗ trợ để tạo ra ý tưởng cho sản phẩm mới. Người quản lý biên soạn các kết quả của các phiên họp động não vào một tài liệu 100 trang. Ông gọi đây là một đặc tả yêu cầu, nhưng trong thực tế nó là gì khác hơn là một đống thông tin. Thông tin từ các bãi não của tất cả những người thông minh không được phân thành nhiều loại khác nhau, tổ chức hợp lý, phân tích, hoặc chế biến thành bất cứ điều gì mô tả một giải pháp phần mềm được đề nghị. Các nhà phát triển không thể lượm lặt những gì họ cần biết về các sản phẩm mới từ bộ sưu tập đồ sộ này của ý tưởng. Chắc chắn có những nuggets của giá trị yêu cầu chôn cất trong số tất cả các lớp trấu. Nhưng chỉ đơn giản là thu thập những ý tưởng thô và nhu cầu vào một danh sách dài không phải là một cách hiệu quả để tài liệu và giao tiếp yêu cầu phần mềm. Thông tin liên lạc rõ ràng và hiệu quả là nguyên tắc cốt lõi của yêu cầu phát triển, thông tin liên lạc từ những người có nhu cầu cho những người có thể nhận thức các giải pháp, sau đó đến những người có thể thực hiện và xác minh những giải pháp. Một nhà phân tích kinh doanh lành nghề sẽ chọn những cách hiệu quả nhất để giao tiếp với từng loại yêu cầu thông tin cho mỗi khán giả. Kết quả của việc phát triển các yêu cầu là một thỏa thuận giữa các bên tờ chi về các sản phẩm được xây dựng. Như bạn đã thấy trong các chương trước, tầm nhìn và phạm vi tài liệu chứa các yêu cầu kinh doanh, và yêu cầu người sử dụng có thể được chụp trong các hình thức trường hợp sử dụng hay những câu chuyện của người dùng. Yêu cầu chức năng và phi chức năng của sản phẩm thường được lưu trữ trong một đặc tả yêu cầu phần mềm SRS, mà là giao cho những người phải thiết kế, xây dựng, và xác minh các giải pháp. Ghi yêu cầu trong một cách có tổ chức mà các bên liên quan chính của dự án có thể xem lại giúp đảm bảo rằng họ biết những gì họ đang đồng ý. Chương này đề cập đến mục đích, cấu trúc và nội dung của SRS. Chúng tôi sẽ mô tả các SRS như là một tài liệu, nhưng nó không phải là trong các hình thức của một tài liệu word-chế biến truyền thống. Trong thực tế, tài liệu đặt ra nhiều hạn chế: ■ Thật khó để lưu trữ thuộc tính mô tả cùng với yêu cầu. ■ Quản lý thay đổi là vụng về. ■ Thật khó để giữ lại phiên bản lịch sử của các yêu cầu. ■ Thật không dễ dàng để tập hợp con ra một phần của yêu cầu đó là phân bổ cho một sự lặp lại cụ thể hoặc theo dõi những người mà đã từng được phê duyệt nhưng sau đó trì hoãn hoặc hủy bỏ. 181 ■ Thật khó để theo dõi các yêu cầu để tạo tác phát triển khác. ■ Nhân bản một yêu cầu mà một cách hợp lý phù hợp ở nhiều nơi gây ra các vấn đề bảo trì. Khi lựa chọn thay thế, bạn có thể lưu trữ thông tin trong một bảng tính (trong đó có rất nhiều các hạn chế tương tự như một tài liệu), một Wiki, một cơ sở dữ liệu, hoặc một công cụ quản lý yêu cầu (RM) (xem Chương 30, "Công cụ cho các yêu cầu kỹ thuật"). Hãy nghĩ về những kho có thể là khác nhau hoặc các thùng chứa để yêu cầu thông tin. Không có vấn đề gì hình thức yêu cầu kho bạn sử dụng, bạn vẫn cần những loại thông tin đó. The SRS mẫu mô tả ở đây là một lời nhắc nhở hữu ích của thông tin để thu thập và làm thế nào bạn có thể tổ chức nó. Không phải ai cũng đồng ý rằng nó có giá trị thời gian để tài liệu yêu cầu. Và các dự án thăm dò hoặc bay hơi cao mà bạn không chắc chắn những gì giải pháp bạn sẽ kết thúc với, cố gắng để theo kịp với những thay đổi trong các chi tiết yêu cầu tăng thêm ít giá trị. Tuy nhiên, chi phí của kiến thức về ghi là nhỏ so với chi phí có được kiến thức đó hoặc tái tạo nó tại một số điểm trong tương lai. Các hành vi đặc điểm kỹ thuật và mô hình giúp đỡ người tham gia dự án cho rằng thông qua và điều chính nhà nước quan trọng là một cuộc thảo luận bằng lời nói có thể để lại mơ hồ. Nếu bạn là 100 phần trăm nhất định mà các bên liên quan không bao giờ sẽ cần một phần cụ thể của thông tin quá thời gian của ký ức ngắn hạn của chính mình, sau đó bạn không cần ghi lại nó. Nếu không, lưu trữ nó trong một số loại của một bộ nhớ nhóm. Bạn sẽ không bao giờ có được yêu cầu hoàn hảo. Hãy nhớ rằng bạn đang viết các yêu cầu đối với khán giả nhất định. Số lượng chi tiết, các loại thông tin mà bạn cung cấp, và cách bạn tổ chức tất cả nên được dùng để đáp ứng nhu cầu của khán giả của bạn. Các nhà phân tích hoàn toàn tự nhiên viết yêu cầu từ quan điểm riêng của họ xem, nhưng thực sự họ nên viết chúng có ý nghĩa nhất đối với những người phải hiểu các yêu cầu và làm việc dựa trên chúng. Đây là lý do tại sao điều quan trọng là phải có đại diện của những khán giả xem xét các yêu cầu để đảm bảo rằng họ sẽ đáp ứng nhu cầu của họ. Tinh Progressive chi tiết là một nguyên tắc quan trọng cho sự phát triển các yêu cầu hiệu quả. Trên hầu hết các dự án đó là không thực tế và không cần thiết để pin xuống từng chi tiết yêu cầu sớm trong dự án. Thay vào đó, hãy nghĩ về lớp. Bạn cần phải tìm hiểu chỉ đủ về các yêu cầu để có thể tương tự ưu tiên để giao cho công bố sắp tới hoặc lặp đi lặp lại. Sau đó, bạn có thể nhóm chi tiết các yêu cầu trong một thời trang chỉ trong thời gian để cung cấp cho các nhà phát triển đầy đủ thông tin để họ có thể tránh làm lại quá nhiều và không cần thiết. Đừng nghĩ rằng ngay cả những yêu cầu tài liệu tốt nhất để thay thế các cuộc thảo luận đang diễn ra trong suốt dự án. Giữ các đường giao tiếp cởi mở giữa các BA, đội ngũ phát triển, đại diện khách hàng và các bên liên quan khác để họ có thể nhanh chóng giải quyết những vấn đề vô mà sẽ phát sinh. Bạn có thể đại diện cho các yêu cầu phần mềm theo nhiều cách, bao gồm: ■ Vâng cấu trúc và cẩn thận viết tự nhiên ngôn ngữ. ■ mô hình trực quan minh họa quá trình transfornational, bang hệ thống và thay đổi giữa chúng, quan hệ dữ liệu, chảy logic, và như thế. ■ thông số kỹ thuật chính mà xác định yêu cầu bằng cách sử dụng ngôn ngữ đặc tả toán học chính xác. thông số kỹ thuật chính thức cung cấp sự chặt chẽ nhất và chính xác, nhưng vài nhà phát triển phần mềm và thậm chí ít khách hàng-quen thuộc với họ. Hầu hết các dự án không yêu cầu mức độ trang trọng, nhưng tôi chắc chắn sẽ hy vọng rằng các nhà thiết kế của hệ thống có nguy cơ cao như các hệ thống điều khiển nhà máy điện hạt nhân sử dụng phương pháp đặc tả hình thức. Ngôn ngữ tự nhiên có cấu trúc, tăng cường với các mô hình trực quan và kỹ thuật biểu diễn khác (chẳng hạn như bàn, mô hình, hình ảnh, và các biểu thức toán học), vẫn là cách thiết thực nhất đối với hầu hết các dự án phần mềm để ghi lại các yêu cầu của họ. Phần còn lại của chương này đề cập đến làm thế nào bạn có thể tổ chức các thông tin trong một đặc tả yêu cầu phần mềm. Chương 11, "Viết yêu cầu tuyệt vời", mô tả đặc điểm của các yêu cầu chất lượng cao và cung cấp nhiều gợi ý về cách viết chúng. 1. [Yêu cầu khác] Xác định các yêu cầu khác mà không được ở nơi khác trong SRS. Ví dụ như việc tuân thủ các tiêu chuẩn và yêu cầu pháp lý, quy định, hoặc tài chính; yêu cầu để cài đặt sản phẩm, cấu hình, khởi động, và tắt máy; và yêu cầu khai thác gỗ, giám sát và kiểm định. Thay vì chỉ cần kết hợp các bài dưới "khác," thêm bất kỳ phần mới cho mẫu là thích hợp cho dự án của bạn. Bỏ qua phần này nếu tất cả các yêu cầu của bạn được cung cấp chỗ ở trong các phần khác. Yêu cầu chuyển đổi đó là cần thiết cho việc chuyển đổi từ một hệ thống trước đó để một hình mới có thể được bao gồm ở đây nếu chúng liên quan đến phần mềm được viết (như đối với các chương trình chuyển đổi dữ liệu), hoặc trong kế hoạch quản lý dự án nếu họ không (như đối với phát triển đào tạo hoặc chuyển phát .) Phụ lục A: Glossary Xác định bất kỳ điều khoản đặc biệt mà một người đọc cần biết để hiểu được SRS, bao gồm chữ viết tắt và viết tắt. Đánh vần từng chữ viết tắt và cung cấp định nghĩa của nó. Xem xét xây dựng một bảng chú giải mức doanh nghiệp tái sử dụng mà kéo dài nhiều dự án và kết hợp bằng cách tham khảo các điều khoản có liên quan đến dự án này. Mỗi SRS sau đó sẽ xác định chỉ có những điều khoản cụ thể cho một dự án cá nhân mà không xuất hiện trong phần chú giải cấp doanh nghiệp. Lưu ý rằng dữ liệu định nghĩa thuộc trong từ điển dữ liệu, không phải là thuật ngữ. Phụ lục B: mô hình phân tích phần tùy chọn này bao gồm hoặc các điểm đến mô hình phân tích thích hợp như sơ đồ luồng dữ liệu, cây đặc, sơ đồ trạng thái, biểu đồ thực thể-mối quan hệ. (Xem Chương 12, "Một bức tranh trị giá 1.024 từ.") Thường thì hữu ích hơn cho người đọc nếu bạn kết hợp một số mô hình thành các phần có liên quan của các đặc điểm kỹ thuật thay vì thu thập chúng vào cuối.
Ghi chép các yêu cầu Tại buổi ra mắt của một dự án lớn để xây dựng sản phẩm chủ lực thế hệ tiếp theo của công ty phần mềm thương mại, một nhà quản lý cấp cao đã triệu tập khoảng 60 nhân viên trong một ngày dài off-site "voice-of-the-khách hàng xưởng . "Những nhân viên làm việc với hỗ trợ để tạo ra ý tưởng cho sản phẩm mới. Người quản lý biên soạn các kết quả của các phiên họp động não vào một tài liệu 100 trang. Ông gọi đây là một đặc tả yêu cầu, nhưng trong thực tế nó là gì khác hơn là một đống thông tin. Thông tin từ các bãi não của tất cả những người thông minh không được phân thành nhiều loại khác nhau, tổ chức hợp lý, phân tích, hoặc chế biến thành bất cứ điều gì mô tả một giải pháp phần mềm được đề nghị. Các nhà phát triển không thể lượm lặt những gì họ cần biết về các sản phẩm mới từ bộ sưu tập đồ sộ này của ý tưởng. Chắc chắn có những nuggets của giá trị yêu cầu chôn cất trong số tất cả các lớp trấu. Nhưng chỉ đơn giản là thu thập những ý tưởng thô và nhu cầu vào một danh sách dài không phải là một cách hiệu quả để tài liệu và giao tiếp yêu cầu phần mềm. Thông tin liên lạc rõ ràng và hiệu quả là nguyên tắc cốt lõi của yêu cầu phát triển, thông tin liên lạc từ những người có nhu cầu cho những người có thể nhận thức các giải pháp, sau đó đến những người có thể thực hiện và xác minh những giải pháp. Một nhà phân tích kinh doanh lành nghề sẽ chọn những cách hiệu quả nhất để giao tiếp với từng loại yêu cầu thông tin cho mỗi khán giả. Kết quả của việc phát triển các yêu cầu là một thỏa thuận giữa các bên tờ chi về các sản phẩm được xây dựng. Như bạn đã thấy trong các chương trước, tầm nhìn và phạm vi tài liệu chứa các yêu cầu kinh doanh, và yêu cầu người sử dụng có thể được chụp trong các hình thức trường hợp sử dụng hay những câu chuyện của người dùng. Yêu cầu chức năng và phi chức năng của sản phẩm thường được lưu trữ trong một đặc tả yêu cầu phần mềm SRS, mà là giao cho những người phải thiết kế, xây dựng, và xác minh các giải pháp. Ghi yêu cầu trong một cách có tổ chức mà các bên liên quan chính của dự án có thể xem lại giúp đảm bảo rằng họ biết những gì họ đang đồng ý. Chương này đề cập đến mục đích, cấu trúc và nội dung của SRS. Chúng tôi sẽ mô tả các SRS như là một tài liệu, nhưng nó không phải là trong các hình thức của một tài liệu word-chế biến truyền thống. Trong thực tế, tài liệu đặt ra nhiều hạn chế: ■ Thật khó để lưu trữ thuộc tính mô tả cùng với yêu cầu. ■ Quản lý thay đổi là vụng về. ■ Thật khó để giữ lại phiên bản lịch sử của các yêu cầu. ■ Thật không dễ dàng để tập hợp con ra một phần của yêu cầu đó là phân bổ cho một sự lặp lại cụ thể hoặc theo dõi những người mà đã từng được phê duyệt nhưng sau đó trì hoãn hoặc hủy bỏ. 181 ■ Thật khó để theo dõi các yêu cầu để tạo tác phát triển khác. ■ Nhân bản một yêu cầu mà một cách hợp lý phù hợp ở nhiều nơi gây ra các vấn đề bảo trì. Khi lựa chọn thay thế, bạn có thể lưu trữ thông tin trong một bảng tính (trong đó có rất nhiều các hạn chế tương tự như một tài liệu), một Wiki, một cơ sở dữ liệu, hoặc một công cụ quản lý yêu cầu (RM) (xem Chương 30, "Công cụ cho các yêu cầu kỹ thuật"). Hãy nghĩ về những kho có thể là khác nhau hoặc các thùng chứa để yêu cầu thông tin. Không có vấn đề gì hình thức yêu cầu kho bạn sử dụng, bạn vẫn cần những loại thông tin đó. The SRS mẫu mô tả ở đây là một lời nhắc nhở hữu ích của thông tin để thu thập và làm thế nào bạn có thể tổ chức nó. Không phải ai cũng đồng ý rằng nó có giá trị thời gian để tài liệu yêu cầu. Và các dự án thăm dò hoặc bay hơi cao mà bạn không chắc chắn những gì giải pháp bạn sẽ kết thúc với, cố gắng để theo kịp với những thay đổi trong các chi tiết yêu cầu tăng thêm ít giá trị. Tuy nhiên, chi phí của kiến thức về ghi là nhỏ so với chi phí có được kiến thức đó hoặc tái tạo nó tại một số điểm trong tương lai. Các hành vi đặc điểm kỹ thuật và mô hình giúp đỡ người tham gia dự án cho rằng thông qua và điều chính nhà nước quan trọng là một cuộc thảo luận bằng lời nói có thể để lại mơ hồ. Nếu bạn là 100 phần trăm nhất định mà các bên liên quan không bao giờ sẽ cần một phần cụ thể của thông tin quá thời gian của ký ức ngắn hạn của chính mình, sau đó bạn không cần ghi lại nó. Nếu không, lưu trữ nó trong một số loại của một bộ nhớ nhóm. Bạn sẽ không bao giờ có được yêu cầu hoàn hảo. Hãy nhớ rằng bạn đang viết các yêu cầu đối với khán giả nhất định. Số lượng chi tiết, các loại thông tin mà bạn cung cấp, và cách bạn tổ chức tất cả nên được dùng để đáp ứng nhu cầu của khán giả của bạn. Các nhà phân tích hoàn toàn tự nhiên viết yêu cầu từ quan điểm riêng của họ xem, nhưng thực sự họ nên viết chúng có ý nghĩa nhất đối với những người phải hiểu các yêu cầu và làm việc dựa trên chúng. Đây là lý do tại sao điều quan trọng là phải có đại diện của những khán giả xem xét các yêu cầu để đảm bảo rằng họ sẽ đáp ứng nhu cầu của họ. Tinh Progressive chi tiết là một nguyên tắc quan trọng cho sự phát triển các yêu cầu hiệu quả. Trên hầu hết các dự án đó là không thực tế và không cần thiết để pin xuống từng chi tiết yêu cầu sớm trong dự án. Thay vào đó, hãy nghĩ về lớp. Bạn cần phải tìm hiểu chỉ đủ về các yêu cầu để có thể tương tự ưu tiên để giao cho công bố sắp tới hoặc lặp đi lặp lại. Sau đó, bạn có thể nhóm chi tiết các yêu cầu trong một thời trang chỉ trong thời gian để cung cấp cho các nhà phát triển đầy đủ thông tin để họ có thể tránh làm lại quá nhiều và không cần thiết. Đừng nghĩ rằng ngay cả những yêu cầu tài liệu tốt nhất để thay thế các cuộc thảo luận đang diễn ra trong suốt dự án. Giữ các đường giao tiếp cởi mở giữa các BA, đội ngũ phát triển, đại diện khách hàng và các bên liên quan khác để họ có thể nhanh chóng giải quyết những vấn đề vô mà sẽ phát sinh. Bạn có thể đại diện cho các yêu cầu phần mềm theo nhiều cách, bao gồm: ■ Vâng cấu trúc và cẩn thận viết tự nhiên ngôn ngữ. ■ mô hình trực quan minh họa quá trình transfornational, bang hệ thống và thay đổi giữa chúng, quan hệ dữ liệu, chảy logic, và như thế. ■ thông số kỹ thuật chính mà xác định yêu cầu bằng cách sử dụng ngôn ngữ đặc tả toán học chính xác. thông số kỹ thuật chính thức cung cấp sự chặt chẽ nhất và chính xác, nhưng vài nhà phát triển phần mềm và thậm chí ít khách hàng-quen thuộc với họ. Hầu hết các dự án không yêu cầu mức độ trang trọng, nhưng tôi chắc chắn sẽ hy vọng rằng các nhà thiết kế của hệ thống có nguy cơ cao như các hệ thống điều khiển nhà máy điện hạt nhân sử dụng phương pháp đặc tả hình thức. Ngôn ngữ tự nhiên có cấu trúc, tăng cường với các mô hình trực quan và kỹ thuật biểu diễn khác (chẳng hạn như bàn, mô hình, hình ảnh, và các biểu thức toán học), vẫn là cách thiết thực nhất đối với hầu hết các dự án phần mềm để ghi lại các yêu cầu của họ. Phần còn lại của chương này đề cập đến làm thế nào bạn có thể tổ chức các thông tin trong một đặc tả yêu cầu phần mềm. Chương 11, "Viết yêu cầu tuyệt vời", mô tả đặc điểm của các yêu cầu chất lượng cao và cung cấp nhiều gợi ý về cách viết chúng. 1. [Yêu cầu khác] Xác định các yêu cầu khác mà không được ở nơi khác trong SRS. Ví dụ như việc tuân thủ các tiêu chuẩn và yêu cầu pháp lý, quy định, hoặc tài chính; yêu cầu để cài đặt sản phẩm, cấu hình, khởi động, và tắt máy; và yêu cầu khai thác gỗ, giám sát và kiểm định. Thay vì chỉ cần kết hợp các bài dưới "khác," thêm bất kỳ phần mới cho mẫu là thích hợp cho dự án của bạn. Bỏ qua phần này nếu tất cả các yêu cầu của bạn được cung cấp chỗ ở trong các phần khác. Yêu cầu chuyển đổi đó là cần thiết cho việc chuyển đổi từ một hệ thống trước đó để một hình mới có thể được bao gồm ở đây nếu chúng liên quan đến phần mềm được viết (như đối với các chương trình chuyển đổi dữ liệu), hoặc trong kế hoạch quản lý dự án nếu họ không (như đối với phát triển đào tạo hoặc chuyển phát .) Phụ lục A: Glossary Xác định bất kỳ điều khoản đặc biệt mà một người đọc cần biết để hiểu được SRS, bao gồm chữ viết tắt và viết tắt. Đánh vần từng chữ viết tắt và cung cấp định nghĩa của nó. Xem xét xây dựng một bảng chú giải mức doanh nghiệp tái sử dụng mà kéo dài nhiều dự án và kết hợp bằng cách tham khảo các điều khoản có liên quan đến dự án này. Mỗi SRS sau đó sẽ xác định chỉ có những điều khoản cụ thể cho một dự án cá nhân mà không xuất hiện trong phần chú giải cấp doanh nghiệp. Lưu ý rằng dữ liệu định nghĩa thuộc trong từ điển dữ liệu, không phải là thuật ngữ. Phụ lục B: mô hình phân tích phần tùy chọn này bao gồm hoặc các điểm đến mô hình phân tích thích hợp như sơ đồ luồng dữ liệu, cây đặc, sơ đồ trạng thái, biểu đồ thực thể-mối quan hệ. (Xem Chương 12, "Một bức tranh trị giá 1.024 từ.") Thường thì hữu ích hơn cho người đọc nếu bạn kết hợp một số mô hình thành các phần có liên quan của các đặc điểm kỹ thuật thay vì thu thập chúng vào cuối.
đang được dịch, vui lòng đợi..
Các ngôn ngữ khác
Hỗ trợ công cụ dịch thuật: Albania, Amharic, Anh, Armenia, Azerbaijan, Ba Lan, Ba Tư, Bantu, Basque, Belarus, Bengal, Bosnia, Bulgaria, Bồ Đào Nha, Catalan, Cebuano, Chichewa, Corsi, Creole (Haiti), Croatia, Do Thái, Estonia, Filipino, Frisia, Gael Scotland, Galicia, George, Gujarat, Hausa, Hawaii, Hindi, Hmong, Hungary, Hy Lạp, Hà Lan, Hà Lan (Nam Phi), Hàn, Iceland, Igbo, Ireland, Java, Kannada, Kazakh, Khmer, Kinyarwanda, Klingon, Kurd, Kyrgyz, Latinh, Latvia, Litva, Luxembourg, Lào, Macedonia, Malagasy, Malayalam, Malta, Maori, Marathi, Myanmar, Mã Lai, Mông Cổ, Na Uy, Nepal, Nga, Nhật, Odia (Oriya), Pashto, Pháp, Phát hiện ngôn ngữ, Phần Lan, Punjab, Quốc tế ngữ, Rumani, Samoa, Serbia, Sesotho, Shona, Sindhi, Sinhala, Slovak, Slovenia, Somali, Sunda, Swahili, Séc, Tajik, Tamil, Tatar, Telugu, Thái, Thổ Nhĩ Kỳ, Thụy Điển, Tiếng Indonesia, Tiếng Ý, Trung, Trung (Phồn thể), Turkmen, Tây Ban Nha, Ukraina, Urdu, Uyghur, Uzbek, Việt, Xứ Wales, Yiddish, Yoruba, Zulu, Đan Mạch, Đức, Ả Rập, dịch ngôn ngữ.
- Best regards,
- Методические (типовые) рекомендациипо пр
- Thật sự 2 tấm bia này cũng là những tư l
- yourselfyour familyentertainment and hob
- Gia đình nhiều thế hệ tạo nên an ninh xã
- nguyên nhân của tình trạng suy thoái môi
- you ought to go home and have a rest you
- We present Collocation Assistant, a prot
- you ought to go home and have a rest you
- con đến hà nội vào sáng sớm,khoảng 5 giờ
- What else are you waiting without perfor
- con đến hà nội vào sáng sớm,khoảng 5 giờ
- Anh biết rằng
- Những người tôi yêu thương đều biến mất
- ngày nay điện thoại la một người bạn với
- IntroductionIndividuals in the U.S. enga
- If we are both free, we can meet
- Tôi luôn cầu chúc cho bạn được nhiều sức
- 昵称：黄秋生字小草号遠志又名黄老邪所在地：香港性别：男生日：1961年9月2日简
- Методические (типовые) рекомендациипо пр
- Nó là một quốc đảo
- nhớ rằng
- Are the Mangas in your shops expensive t
- yourselfyour familyentertainment and hob
