Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Жүйелік инженериядағы талаптарды анықтау және сақтау
Defining and maintaining requirements in systems engineering
Талаптарды жасау (RE) – инженерлік жобалау процесінде талаптарды анықтау, құжаттау және сақтау процесі. Бұл жүйелік инженерия және бағдарламалық жасақтама инженериясында кең таралған рөл. «Талаптарды жасау» термині алғаш рет 1964 жылы «Maintenance, Maintainability, and System Requirements Engineering» конференциясында қолданылған болуы мүмкін, бірақ ол 1990-шы жылдардың соңында IEEE Computer Society-дің 1997 жылғы наурыз айында жарияланған оқу құралы және талаптарды жасау жөніндегі конференциялар сериясының құрылуымен ғана кеңінен қолданысқа енді. Бұл конференциялар сериясы Халықаралық талаптарды жасау конференциясына (International Requirements Engineering Conference) айналды. Суарна модельде талаптарды жасау даму процесінің алғашқы кезеңі ретінде қарастырылады. Кейінгі даму әдістері, соның ішінде бағдарламалық жасақтама үшін Рационалды біріктірілген процесс (RUP), талаптарды жасау жүйе өмірінің бойында жалғаса береді деп есептейді. Жүйелік инженерия практикасының бір бөлігі болып табылатын талаптарды басқару, Халықаралық жүйелік инженерия кеңесінің (INCOSE) нұсқаулықтарында да көрсетілген.
Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering. The first use of the term requirements engineering was probably in 1964 in the conference paper "Maintenance, Maintainability, and System Requirements Engineering", but it did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial in March 1997 and the establishment of a conference series on requirements engineering that has evolved into the International Requirements Engineering Conference. In the waterfall model, requirements engineering is presented as the first phase of the development process. Later development methods, including the Rational Unified Process (RUP) for software, assume that requirements engineering continues through a system's lifetime. Requirements management, which is a sub function of Systems Engineering practices, is also indexed in the International Council on Systems Engineering (INCOSE) manuals.
Іс-шаралар
Талаптар инженериясымен байланысты қызметтер әзірленіп жатқан жүйенің түріне және ұйымның нақты тәжірибесіне қарай кең ауқымды болады. Оларға мыналар жатады:
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the organization's specific practice(s) involved. These may include:
Талаптарды қабылдау немесе талаптарды іздестіру – Дамушылар мен мүдделі тараптар кездеседі, соңғылары бағдарламалық өнімге қатысты қажеттіліктері мен тілектері туралы сұралады. Талаптарды талдау және келіссөздер жүргізу – Талаптар анықталады (даму итеративті болса, жаңаларын қоса алғанда), мүдделі тараптармен келіспеушіліктер шешіледі. Жазбаша және графикалық құралдар (соңғысы көбінесе жобалау кезеңінде қолданылады, бірақ кейбіреулер оларды осы кезеңде де пайдалы деп санайды) көмекші құрал ретінде табысты қолданылады. Жазбаша талдау құралдарының мысалдары: қолданыс сценарийлері және пайдаланушы оқиғалары. Графикалық құралдардың мысалдары: UML және LML. Жүйелік модельдеу – Кейбір инженерлік салалар (немесе нақты жағдайлар) өнімнің құрылысын немесе өндірісін бастамас бұрын толық жобаланып, модельделуін қажет етеді. Сондықтан жобалау кезеңі алдын ала орындалуы тиіс. Мысалы, ғимаратқа келісімшарт бекітіліп, қол қойылмас бұрын жобасы дайындалуы керек. Көптеген салалар жүйе модельдерін Өмірлік цикл модельдеу тілімен (Lifecycle Modeling Language) құрастырады, ал басқалары UML-ді пайдаланады. Ескерту: Көптеген салаларда, мысалы бағдарламалық жасақтама инженериясында, модельдеу қызметтерінің көпшілігі талаптар инженериясы емес, жобалау қызметтері ретінде жіктеледі. Талаптар спецификациясы – Талаптар талаптар спецификациясы (ТС) деп аталатын ресми құжатқа жазылады, ол тек расталғаннан кейін ғана ресми күшке енеді. ТС қажет болған жағдайда жазбаша және графикалық (модельдер) ақпаратты қамти алады. Мысал: Бағдарламалық қамтамасыз ету талаптарының спецификациясы (SRS). Талаптарды тексеру – Құжатталған талаптар мен модельдердің дұрыстығын және мүдделі тараптардың қажеттіліктерін қанағаттандыратынын тексеру. Тек соңғы нұсқа тексеруден өткен жағдайда ғана ТС ресми болады. Талаптарды басқару – Талаптарды қабылдаудан бастап, жүйенің дамуын бақылау және тіпті пайдалануға бергеннен кейін де (мысалы, өзгерістер, кеңейтулер және т.б.) олармен байланысты барлық қызметтерді басқару. Бұл қызметтер кейде хронологиялық кезеңдер ретінде ұсынылса да, іс жүзінде олардың арасында үлкен байланыс болады. Талаптар инженериясы бағдарламалық жасақтама жобаларының сәтті болуына айқын үлес қосатыны дәлелденді.
Requirements inception or requirements elicitation – Developers and stakeholders meet; the latter are inquired concerning their needs and wants regarding the software product. Requirements analysis and negotiation – Requirements are identified (including new ones if the development is iterative), and conflicts with stakeholders are solved. Both written and graphical tools (the latter commonly used in the design phase, but some find them helpful at this stage, too) are successfully used as aids. Examples of written analysis tools: use cases and user stories. Examples of graphical tools: UML and LML. System modeling – Some engineering fields (or specific situations) require the product to be completely designed and modeled before its construction or fabrication starts. Therefore, the design phase must be performed in advance. For instance, blueprints for a building must be elaborated before any contract can be approved and signed. Many fields might derive models of the system with the Lifecycle Modeling Language, whereas others, might use UML. Note: In many fields, such as software engineering, most modeling activities are classified as design activities and not as requirement engineering activities. Requirements specification – Requirements are documented in a formal artifact called a Requirements Specification (RS), which will become official only after validation. A RS can contain both written and graphical (models) information if necessary. Example: Software requirements specification (SRS). Requirements validation – Checking that the documented requirements and models are consistent and meet the stakeholder's needs. Only if the final draft passes the validation process, the RS becomes official. Requirements management – Managing all the activities related to the requirements since inception, supervising as the system is developed, and even until after it is put into use (e. g., changes, extensions, etc.) These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities. Requirements engineering has been shown to clearly contribute to software project successes.
Қиындықтар
Германияда жүргізілген бір шектеулі зерттеу талаптарды жобалауды іске асыруда туындауы мүмкін проблемаларды көрсетті және сауалнамаға қатысушылардан олардың шынайы проблемалар екендігіне келіседі-келіспейтінін сұрады. Зерттеу нәтижелері жалпылама емес деп көрсетілді, бірақ негізгі проблемалар толық емес талаптар, өзгеріп отыратын мақсаттар және уақыт шектеулері болды, ал коммуникациядағы қателер, іздеуге болмау, терминологиялық қиындықтар және жауапкершіліктің белгісіздігі сияқты мәселелер аз болды.
One limited study in Germany presented possible problems in implementing requirements engineering and asked respondents whether they agreed that they were actual problems. The results were not presented as being generalizable but suggested that the principal perceived problems were incomplete requirements, moving targets, and time boxing, with lesser problems being communications flaws, lack of traceability, terminological problems, and unclear responsibilities.
Сын
Проблеманы құрылымдау, қажеттіліктерді инженерияның маңызды аспектісі, жобалау өнімділігін төмендетуі мүмкін деген болжам бар. Зерттеулер көрсетіп тұрғандай, егер қажеттіліктерді инженерия процесінде кемшіліктер болса, нақты талаптардың болмауына қарамастан, бағдарламалық жасақтама талаптары жасалуы мүмкін, бұл жағдайда жобалау шешімдері талаптар ретінде қате көрсетіліп, иллюзия тудыруы мүмкін.
Problem structuring, a key aspect of requirements engineering, has been speculated to reduce design performance. Some research suggests that it is possible if there are deficiencies in the requirements engineering process resulting in a situation where requirements do not exist, software requirements may be created regardless as an illusion misrepresenting design decisions as requirements