Защо трябва да разбирате софтуерните изисквания като софтуерен инженер

В тази статия ще научите всичко за софтуерните изисквания. Ще получите описание на тематичната област, процеса и най-важното какви са вашите отговорности в тази област като софтуерен инженер.

Трябва да придобиете известна представа за вашата роля и дейности със софтуерните изисквания. Ако не друго, ще имате какво да обсъдите с колегите след следващия си stand-up?

Тази статия заимства сериозно от тома, който е ръководството за IEEE SWEBOK. Той се опитва да дестилира част от това знание, като го преназначи по-кратко. В случай, че се чудите, SWEBOK е съкращение от Софтуерно инженерство на знанието, което се поддържа от IEEE Computer Society

Предварително, защо е важно това?

Има погрешно схващане от тези, които не са в софтуерното инженерство, че ролята на софтуерен инженер е просто да „пише код“.

Да, ние сме технолози, които обикновено обичат да учат програмиране. В действителност това е опростена гледна точка, която подценява това, което всъщност прави професионалистът от софтуерен инженер в ежедневната си работа и кариера. Той се фокусира само върху част от общите им отговорности.

Ролята на софтуерния инженер е да изгражда бизнес решения в корпоративен мащаб. Това включва голям брой отговорности, които не са свързани с кода, който те създават.

Една област на отговорност, която имате като професионален софтуерен инженер, е областта на софтуерните изисквания.

Какви са софтуерните изисквания?

Софтуерните изисквания на повърхността звучат просто. Софтуерът трябва да направи X за Y, така че Z. Помислете достатъчно дълго за всеки проблем, който софтуерът може да реши (или за съществуващ софтуер, който вече решава проблем) и вероятно бихте могли да обмислите голям брой изисквания. Лесно нали?

Ами не, всъщност за повечето корпоративен софтуер.

Как събирате вашите изисквания? Обмисляте ли нуждите и приоритетите на заинтересованите страни? Това наистина ли е изискване за потребителите на софтуера? Има ли технически ограничения на съображенията? Как да разберете кога е направено? Изпълнението на изискването отговаря ли на зададен критерий? И така нататък...

Когато започнете да разглеждате идеята за изискванията на софтуера, откривате, че те крият голяма и по-дълбока област на знанието.

Колко дълбока и голяма област от знания? SWEBOK определя областта на софтуерните изисквания като „ свързана с извличането, анализа, спецификацията и валидирането на софтуерните изисквания, както и управлението на изискванията през целия жизнен цикъл на софтуерния продукт “.

Размерът на тази област, като например броя на дейностите и доколко могат да бъдат включени, даде достатъчно доверие, за да се посвети един отрасъл инженерство, известен като „ инженеринг на изискванията “, фокусиран единствено върху процеса на изискванията.

Някои организации могат да наемат специално за ролята на инженер по изискванията. Можете да видите това по-често в наистина големи организации, които предлагат решения на системно ниво, например, когато предложените от тях решения на проблемите на клиентите включват цялостно решение, от което софтуерът е само един компонент.

По-често организациите са склонни да споделят изискванията към инженерната отговорност чрез дейности, възложени между различните други роли на проекта, като дизайнери, бизнес анализатори, собственици на продукти, управление на клиенти, предлагане на технически специалисти, софтуерни архитекти / инженери и т.н.

Като цяло е трудно да се приложи процесът на изискванията в линеен процес на практика, като методология на водопада. Това би изисквало изискванията за софтуер да бъдат извлечени от заинтересованите страни, класифицирани, разпределени и в крайна сметка предадени за изпълнение от екипа за разработка на софтуер. Това често е невъзможно за дългосрочни мащабни успешни решения.

Изискванията за тези големи софтуерни проекти никога не са напълно разбрани или напълно уточнени. Вместо това те обикновено се повтарят до достатъчно ниво на качество и детайлност, което позволява да се вземат решения за проектиране и възлагане на поръчки.

Инженерингът на изискванията се различава от софтуерното инженерство по типа работа, върху която се фокусирате.

Важно е да разберете връзката си с процеса на изисквания, тъй като вероятно в даден момент ще бъдете въвлечени в някои дейности по изискванията.

Какво включва софтуерните изисквания за софтуерния инженер?

В зависимост от процеса на изисквания на вашата организация и / или дейностите по изискванията, за които отговаря софтуерният инженер, може да участвате във всеки или във всички етапи. Това може да бъде от събиране на изисквания до проверка на тяхното изпълнение.

Области, в които може да участвате:

  • Извличане - събиране на изисквания за софтуера
  • Класификация - категоризиране на изискването
  • Валидиране - потвърждаване на изискването със заинтересованите страни
  • Разработка и внедряване - изграждане на софтуера, който да отговаря на изискванията
  • Преговори - справяне с конфликти на интереси на заинтересованите страни
  • Проверка - оценката на софтуерната функция отговаря на изискването

Струва си да се отбележи, че това не е дубликат на инженерния процес на изискванията. Те изискват по-дълбоко ниво на участие и видове дейности с определени области, като управление и документиране на изискванията.

Управлението и документирането на изискванията обикновено не е ваша отговорност. Вероятно това ще бъде отговорността за другите роли, които споделят изискванията.

Важно е да знаете как да получите достъп и да използвате системата за управление на изискванията за оценка на промените в изискванията и анализ на въздействието.

Хм, няма система за управление на изискванията ...

В някои случаи записването и управлението на изискванията може да не са в специализирана система. Те могат да бъдат записани в други видове системи за запис, като софтуер за проследяване на проблеми, инструменти за управление на проекти или може би дори система за контрол на версиите.

В други случаи организациите или екипите по проекти не разработват средства за документиране и управление на изискванията. Вместо това те могат да разчитат на визията за лидерство (отделен човек или екип с обичайния пример е основателят на компанията) и / или имат ограничени ресурси. Те могат да противопоставят, че изискванията за запис или управление не са необходими.

Незаписването и управлението на изискванията може потенциално да представлява сериозен риск за организацията и процеса на софтуерното решение.

Например вашата организация, която разработва решения за нуждите на клиентите, ще трябва да изпълни определени законови задължения. Те ще заявят, че вашият софтуерен компонент е създаден да предоставя определена функционалност и е в състояние да предостави определено ниво на услуга (SLA).

Но ако трябва да възникне конфликт (правен или по друг начин), може би липсваща част от функционалността, нефункционално изискване не функционира според очакванията или дори време / бюджет, изразходвани за нежелани функции, как да покажете какво е било приложено какво е било договорено от заинтересованите страни, както е необходимо и необходимо?

Вашата организация трябва да може да демонстрира съпоставянето между изискванията за решение на високо ниво (това, от което клиентът се нуждае като решение), и валидираните софтуерни изисквания (това, което заинтересованите страни се съгласиха да отговарят на функционалните нужди на решението, а не непременно 1 към 1) до внедряване на документация и записване на тестове за приемане или ниво на обслужване, които показват предоставената функционалност.

Друг по-често срещан (и по-малко измислен) пример е оценката на въздействието. Тъй като вашата организация или екип от проекти расте и се развива, нараства и софтуерът, който създавате. Освен ако софтуерът не е предназначен да бъде излишен, той трябва да работи за определен период от време и така ще бъде обект на надстройки, нови функции и поддръжка.

Тази нова работа може да отмени, въздейства или промени съществуващата функционалност, проектирана да отговори на исторически изисквания по различни начини (като промяна на софтуерната архитектура или дизайн на компонент).

Ако е така, ще трябва да преразгледате старите изисквания, за да разберете по-добре мотивациите, които го подкрепят. Например, защо беше реализиран по такъв начин? Трябва ли текущата работа да се промени? Старото изискване все още ли е актуално? и т.н.

Изявяване на изисквания за софтуер

Изявяването на изисквания се отнася до дейността, която описва как се събират или събират изискванията. Не всички изисквания се "събират" от клиент и могат да бъдат извлечени от системата или домейна, в който софтуерът работи (като работоспособност и надеждност за критични системи).

От гледна точка на управлението на проекти, извличането е от решаващо значение за извличане на обхвата на проекта и резултатите, важни за нуждите на клиента или потребителя, като първо се приоритизират най-важните нужди.

Какво е свързано с извикването на софтуерни изисквания?

В зависимост от нивото на участие на вашата роля в процеса на изисквания, може да се наложи да вземете изисквания от източника.

Извличането на изисквания помага да се информира за дизайна и архитектурата на цялостното решение. Важно е да разберете откъде идват изискванията и какви техники се използват.

Откъде идват софтуерните изисквания?

Има много източници на изисквания, като например:

  • Цели (известни също като бизнес загриженост, критичен фактор за успех и др.)
  • Познаване на домейн
  • Заинтересовани страни
  • Бизнес правила
  • Оперативна среда

Ако участвате в извличането от източници, ще трябва:

  • Обърнете специално внимание на целите.
    • Те обикновено са неясни, като „Софтуерът трябва да бъде внедрен с помощта на най-добрите практики“ или „Софтуерът трябва да бъде удобен за потребителя“
    • Оценете относителната стойност за приоритет на решението. Проучете относително евтини начини за постигане.
  • Придобиване или разполагане с познания за домейна на приложението
    • Това ви предоставя основна информация, която дава разбиране за причините, които стоят зад изискванията.
    • Разработването на модели на реалния проблем, като модели на взаимоотношения между субектите, са от ключово значение за добрия анализ на софтуерните изисквания. Опитайте се да мислите, използвайки онтологичен подход.
  • Идентифицирайте, представлявайте и управлявайте гледните точки на много различни видове заинтересовани страни
    • Изискванията могат да бъдат противоречиви, припокриващи се или да изискват различни мотиви в части от нуждите на различните заинтересовани страни.
    • Важно е да разпознавате различните нужди, особено при предварителното планиране на изпълнението, където нуждите са включени в дизайна.
  • Покажете чувствителност към работната среда на решението
    • Оперативната среда ще зависи от структурата, културата и вътрешната политика на организацията.
    • Общ принцип, към който трябва да се стреми вашият софтуер, е да не се въвеждат непланирани или принудителни промени в бизнес процеса на организацията.

Как да получа софтуерните изисквания?

Някои основни техники, с които може да се занимавате (предоставяне на технически опит), могат да бъдат:

  • провеждане на интервюта със заинтересовани страни
  • очертаване на сценарии
  • изграждане на прототипи
  • наблюдение в проблемната зона
  • потребителски истории

При изграждането на прототипи, общ принцип, който трябва да опитате да следвате, е да използвате по-често прототипи с ниска точност в тези по-ранни етапи.

Те се предпочитат, за да се избегне фиксирането на заинтересованите страни върху незначителни или случайни характеристики. По-висококачественият прототип може да ограничи гъвкавостта на дизайна по непредвидени начини.

Класификация на софтуерните изисквания

Когато са изискани софтуерни изисквания, те могат да бъдат класифицирани в редица категории от екипа на проекта.

Това помага по различни начини, като например оценка на усилията по проекта, идентифициране на компоненти за проектиране на решение или дори прости съображения за изпълнение.

Видовете класификация могат да включват:

  • Функционални / нефункционални
    • Функционалните изисквания описват функциите, които софтуерът трябва да изпълнява. Например осигуряване на комуникационен канал за потребител или прехвърляне на данни от един формат в друг. Те могат да бъдат известни и като характеристики или възможности на продукта.
    • Нефункционалните изисквания действат, за да налагат определени ограничения върху решението, често по отношение на качеството. Те могат по-нататък да се класифицират в много типове " -връзки " като наличност, надеждност, възстановимост, поддръжка, мащабируемост, производителност, сигурност и т.н.
  • Изведено / наложено / възникващо
    • Изискването произтича ли от други изисквания?
    • Налага ли се изрично изискването от заинтересованата страна?
    • Изискването възникващо свойство ли е? С други думи, той не може да бъде адресиран от един компонент, но зависи от това как всички софтуерни компоненти взаимодействат.
  • Процес / продукт
    • Изискването свързано ли е с продукта? (пример, „ Софтуерът трябва да провери дали дадено лице отговаря на условията “)
    • Свързано ли е с процеса на изискване? (пример, „ Софтуерът трябва да се разработва постепенно и да използва непрекъснати работни процеси на интеграция и внедряване )
  • Приоритет
    • Балансиране на разходите за разработка и внедряване спрямо необходимостта от доставка.
    • Може да използва скала с фиксиран етикет като задължителна, силно желана, желана и незадължителна.
  • Обхват
    • Използва се за разглеждане на въздействието върху софтуерната архитектура и дизайна на компонентите.
    • Нефункционалните лица често имат глобален обхват.
  • Нестабилност / стабилност
    • Потенциалът на изискването ще се промени по време на жизнения цикъл на софтуера.
    • Това ще помогне за изпълнението на проекти, които са толерантни към промените

Проверка на изискванията на софтуера

След като софтуерните изисквания бъдат извлечени и класифицирани, те трябва да бъдат потвърдени със заинтересованите страни за точност и дали те действително отговарят на техните нужди. Изискванията, които не могат да бъдат валидирани, всъщност са просто „желания“ от заинтересованите страни.

Ако следвате итеративен метод за разработка, валидирането на изискванията може да се извършва редовно, разделено по обхват около конкретни области на решение, или предприето на парчета, или някакъв друг вид разделяне, който има логичен смисъл.

Валидирането на изискванията обикновено включва екипа на решението, който възпроизвежда разбирането си за изискването обратно на заинтересованите страни. Той може да включва и първоначален дизайн (бизнес или технически, или и двата), който показва как ще бъде изпълнена всяка от нуждите на заинтересованите страни.

Тези разбирания се създават итеративно през етапите на планиране и обикновено се състоят от възгледите на междуфункционален екип (дизайнери, бизнес анализатори, технически експерти).

В някои случаи дизайнът може да се нуждае от работа преди изпълнението, за да демонстрира по-добре разбирането на екипа, обикновено под формата на функционален прототип.

По време на валидирането вашият екип може да не е в състояние да задоволи напълно изискванията на всяка заинтересована страна. Като технически експерт ще бъдете отговорни да демонстрирате и договаряте компромисите, които отговарят на ограниченията. Трябва да бъде приемливо за основните заинтересовани страни, като същевременно е в рамките на бюджетните, техническите, регулаторните и други мерки.

Използване на функционални прототипи

Функционалните прототипи са полезни, тъй като позволяват:

  • потвърждавайки, че изискванията са разбрани
  • по-лесно тълкуване на предположенията на инженера
  • обратна връзка, която може да осигури нови изисквания

Трябва да имате предвид, че заинтересованите страни могат да бъдат разсеяни от козметични проблеми или проблеми с качеството. Можете да смекчите това чрез последователно съобщаване на истинската важност на демонстрацията - основната основна функционалност.

Начинът на изграждане на прототипа се определя от екипа на вашия проект. Някои застъпници предпочитат прототипи, които избягват изобщо софтуера (подобен на този, създаден при извеждане на изисквания). Други предпочитат някакъв вид софтуерен дисплей чрез набори от инструменти за проектиране или бързо изградена итерация на чернова на софтуера зад контрола на характеристиките.

Какъвто и избор да вземе вашият екип, трябва да вземете предвид скоростта на изграждане на прототипа спрямо ефективността на демонстрирането на основната функционалност.

Разработване и внедряване на софтуерни изисквания

Когато изискването е потвърдено със заинтересованите страни, можете да започнете разработването / изпълнението на изискването.

В много случаи ще действате като софтуерен архитект, тъй като процесът на анализ и разработване на изискванията изисква да бъдат идентифицирани компонентите на архитектурата / дизайна, които ще отговарят за удовлетворяването на изискванията.

Основен интерес за вашата организация е да се възползвате от софтуерното решение. Ваша отговорност е да се опитате да използвате методи, които намаляват разходите за разработка и поддръжка.

Можете да направите това, например чрез повторна употреба на компоненти (вътрешно или от други продукти), като използвате добре дефинирани модели и работите с добре тествани и добре документирани инструменти / рамки.

Специфични изисквания, особено ограничения, могат да окажат огромно влияние върху цената на софтуера. Например, ако уменията ви в изпълнението са лоши или може би изискването е противоположно или не се вписва в текущата архитектура. Важните компромиси между тези изисквания трябва да бъдат идентифицирани на екипа на проекта.

По време на процеса на изисквания, важен момент, който трябва да разберете, е очакването, че значителна част от изискванията ще се промени. Осъзнайте неизбежността на промяната и опитайте да предприемете стъпки във вашия дизайн, за да я направите.

Потребителската история

Софтуерен инженер често работи в контекста на потребителска история. Потребителската история е естествено представяне на взаимодействието на определен тип потребител със софтуера и функционалността, която той трябва да им предоставя. Обикновено следва формата на:

Като, аз искам, така че

Пример:

Като администратор на курса искам да видя броя на хората, записани в курс, за да мога да видя текущия капацитет на курса

В някои случаи потребителската история ще се предлага с дизайн или прототип, ако те са били необходими на етапа на валидиране.

Възможно е историята на потребителя да не е ориентирана към потребителя и вместо това произтича от възникващо свойство или нефункционално изискване. В тези случаи може да получите изискването в различен контекст на доставка (като спецификация или набор от сценарии).

Потребителската история има за цел да съдържа точно достатъчно информация, така че вашият инженерен екип да може да направи разумна оценка на усилията за нейното прилагане. Ако вашият екип не е в състояние да изготви разумна оценка, това може да е признак за лошо съвпадение на знанията / уменията, индивидуалните нива на увереност, приспособяването или ограниченията, или от решаващо значение липсата на качество на потребителската история.

Софтуерните инженери са (задължително) ограничени от плановете за управление на проекти, така че трябва да се опитате да предприемете стъпки, за да проверите дали качеството на изискванията е възможно най-високо, като се имат предвид наличните ресурси.

Преди да бъде внедрена потребителска история, проверете:

  • за подходящи критерии за приемане, писмени или съгласувани със заинтересованите страни, които определят как целите на потребителската история могат да бъдат изпълнени с изпълнението.
    • Това ще формира основата за тестовете за приемане на характеристиката (с други думи, тестовете, които показват изискването е изпълнено).
    • Това също може да е част от дефиницията на екипа за „готово“ или пълно.
  • дизайнът на прототипа (ако е направен) е осъществим и може да се побере в рамките на текущата архитектура, инженерни умения и инструменти, одобрени за използване в проекта.
  • всякакви предположения, които са в основата на изискването.
    • Това може да подчертае пропуски в знанията, потенциални проблеми или други сценарии / крайни случаи, които не се разглеждат и изискват допълнителни разяснения от заинтересованите страни.

Договаряне на софтуерни изисквания

При прилагането на дадено изискване е възможно не всеки интерес на заинтересованите страни да бъде удовлетворен напълно. Това може да се случи например между функционални и нефункционални изисквания или когато изпълнението на едно изискване влияе върху интереса на друга заинтересована страна.

В повечето случаи е неразумно да вземате едностранно решение.

Вместо това вие носите отговорност за оценка на проблема, просто общуване и договаряне на компромиси, които са приемливи за основните заинтересовани страни, като същевременно оставате в рамките на бюджетните, техническите, регулаторните и други ограничения.

Проверка на изискванията на софтуера

Всички софтуерни изисквания изискват необходимостта да бъдат проверявани като функция или функционално изискване или на глобално ниво като нефункционално изискване. Изискванията трябва да бъдат проверени спрямо крайния продукт.

Важна задача за вас е да планирате как да проверите всяко изискване.

Софтуерен инженер проверява изискване, като използва тест за приемане. Тестът за приемане показва как е изпълнено изискването (отговаря на критериите за приемане), като показва поведението на крайния потребител, извършващо бизнес със софтуера, както е дефинирано от изискването.

При изисквания, при които е по-трудно да се демонстрира проверката, като нефункционални изисквания, може да се наложи изградена симулация. Например, за да се тества натоварването на производителността на софтуера, изпълняващ процес на всмукване, може да се създаде софтуер за тестване, който да симулира стотици или хиляди приложения към системата в тест за приемане на черна кутия.

Тъй като софтуерът се развива с течение на времето, прилагането на ново изискване може неволно да повлияе на изпълнението на предварително изпълнено изискване. Тази регресия може да бъде предпазена чрез автоматизиране на тестовете за приемане. Можете да намерите много инструменти и библиотеки, налични за езици за програмиране, които се използват от предприятия, които позволяват автоматизиране на тестовете за приемане.

Не бъркайте теста за приемане като ваша единствена отговорност за тестване. Адекватно се опитайте да обхванете изпълнението с други тестове освен приемане, като модулни или интеграционни тестове.

Тестовете за приемане варират в степента на сложност в зависимост от критериите за приемане. Различните организации също могат да използват различна терминология и практики, което означава, че те могат да бъдат объркани с други видове тестване или да бъдат посочени с различни имена, като тестване от край до край, функционално тестване или тестване на сценарии. Вашата организация може също да има строги критерии или формати, в които се демонстрират тестове за приемане.

Не забравяйте, че ядрото на всеки тест за приемане е просто формална проверка, че внедреното решение отговаря на изискванията на софтуера, като възпроизвежда поведението на потребителите при работещо приложение спрямо крайния продукт.

Това е накратко

Успяхте. Поздрави за вас!

Надявам се, че тази статия е предоставила известна полза от признаването на ролята ви на софтуерен инженер със софтуерни изисквания.

Можете да прочетете повече от моите статии в моя блог.

Тази статия се споделя свободно и авторът не е получил никакъв принос или печалба, както е разрешено от разрешенията за авторско право и повторно отпечатване на SWEBOK. Всички изразени възгледи или мнения не отразяват тези на IEEE или на който и да е орган / организация, към който съм свързан, не е одобрен от IEEE и представлява моето собствено мнение и мнения.